Because you link to a github repository with multiple folders in it. There is no visible website or whatsoever so it seems you need to search through source files form your guide.
A guide should be like a website with chapters which you can browse through, not a repo with .md files.
I dont think it is so bad with Meteor.
We just need to use it for what it is planned and that is live updates over DDP and easy coding.
Keep only reactive services collections(these with live changes where you need live interaction of more users/events) visible from Meteor.
All other should be in different database so they dont spam Meteor’s oplog feed.
And use methods to call to external APIs to get needed static responses. Any REST implementation would do.
Or if you want to be fancy and use userfriendly data requests wire it to external GraphQL/Falcor…
Call method which will provide you results from these private APIs through server, or get them directly from client bypassing server to consume even less server resources if the API is available from public.
Meteor is blazing fast to write code and wire things together. It is not optimal to do simple non-reactive DB queries.
But that is scope of other distributions like for example SailsJS to focus on providing fast and robust APIs.
For future I see myself still using Meteor as primary user managing tool and glue which will be used to wire all microservices together. It does not mean all microservices will be Meteor based.
If you need site which will be served to 1.000.000.000 users, dont need socket connection and all interaction between client and server would be only as a reaction on user action - than yes Meteor is not good for that scenario.
Was it sent to the listserv? I seem to recall it only being announced on the forums, which is good, but everyone checks their email.
Since the troubles exploded,our company is also moving forward. We dont know yet for sure, but it seems Aurelia.io is very promising. So we seem to also replace Meteor for that modern framework.
I think the mailing list was officially shut down in favor of the forums at some point - your best bet is to set up email notifications for the forum.
Yes, that’s the current state. We’re also working on a website for it, hopefully we’ll have an initial version in a month or so.
It will be that way, the repo has a link to the preview, but it is in progress yet… the link to github makes more sense now for the community helping in the ideas.
Here follows the link, remembering that is WIP, the list with the remaining topics to be written are in the github.
See, that’s the part I get angry at - “It’s our way or highway!”. I want a choice - not all our projects are enterprise-grade apps, and those that are, don’t like cutting edge technologies but proven and stabile ones. So, one’s choice to take a highway is completely legitimate and doesn’t necessarily mean that we’re left behind because our businesses will continue to pay our bills. I won’t be surprised if in the next 12 months there will emerge some other platform(s) that will surpass Meteor in many ways.
Absolutely! That was the point - to simplify things. Is React easier to grasp than Blaze? I don’t think so. To me, it only adds more complexity and steep(er) learning curve.
I’d assume you don’t run a business that does weekly paychecks. For whom it was for then? Does ‘Galaxy’ rings any bell? Enterprise/corporate programers are mostly “9-to-5” programmers. What they do in their spare time doesn’t really matter (to employers).
It’s not always about being on the cutting edge. Sometimes (more often than not) it’s about keeping your business’ lights on. From my experience, users/visitors couldn’t care less about the tech behind your site as long as UX rulez.
And sometimes cutting-edge = new features and even paradigm shifting…
These times are crazy, there are a lot of companies that friends work here in Brazil angry with new ways of doing things: i used to work in Vivo, the biggest telco here and its visible they are worried about Whatsapp and Netflix, they are kinds of telecom, but they don’t have the same worries with government and taxes… because they started as just apps and services, now are taking all the area… nobody sends sms and hardly call to say something trivial, whatsapp took all that. Netflix took a great size of paid tv too. Not to talk about the taxis fights in the street about Uber and the hotels taking less with Airbnb.
And it is just the beginning, besides these new ideas and ways of doing things from startups, robotics and AI are becoming mature and will get their place in market causing many harder disruptions… we have to be prepared for this kind of changes… the change itself is the constant now.
I believe realtime apps and fat clients have some role in this story too, providing the path for many of the ideas that will come.
And it isn’t so easy… React, Meteor and others techs are helping it get better.
@miro while working on the Blaze React project I’ve started to see what it would take to integrate all sorts of view frameworks. I think the latest occurrences will only mean more choices. It will soon be trivial to integrate Aurelia, Riot JS, or cycle.js if you want a more functional approach. Blaze also doesn’t need to go anywhere.
What’s happening is a decoupling of the view layer from the rest of Meteor. Blaze already is what it is, man. There’s no where left for it to go. If you want it to evolve more, than you’re better off using the newer view frameworks. But if you want it to evolve more, you yourself are saying you’re willing to integrate changes that would come your way, regardless of whether they came from a Blaze 2.0 or React or other. See what I’m saying. The Blaze story is done. Blaze is pretty damn solid. Production apps run on it. So what I’m saying is this: because Meteor is on its way to being decoupled from the view layer–it’s not like you won’t be using official meteor. The future of Meteor will likely involve lots of view frameworks. Blaze won’t suffer as a result, not anymore than it already does from its own weaknesses. Meteor changes from the rest of the stack will propagate to Blaze, just as they will to Riot or Cycle.js–by virtue of the fact that Meteor is now meant to be used with a plethora of view frameworks.
Now that said, as you’re probably aware, I AM ONE OF THE INDIVIDUALS JUST AS FRUSTRATED AS YOU ABOUT THIS WHOLE THING. But I’ve found ways to make it better. Here’s my deal: I built an entire Blaze 2.0-like framework based on Blaze, only for this news to come out. So for me, that was basically infuriating because–at first–it meant all my hard work was for not. But, since I’ve been working on Sideburns/Blaze-React, etc, I’ve found an even better future. I’ve also managed to integrate my blaze tools into it.
I got a bunch of bright stories to tell over the next few days as I release some things, and I think things are gonna look up again for a lot of people. The choice to migrate your code to React–or have it automatically transpiled to React–is your choice. Blaze will continue to run. Sure, it will be frustrating as all the new packages and package upgrades start to revolve around React. But honestly the current Blaze ecosystem is so rich–that you basically already have everything you need. What I’ve come to realize is I/you/we are basically counting eggs that haven’t hatched by letting this React situation bother us–cuz all it means is there may be some new things, which you can’t have. You’re current Blaze ecosystem isn’t being taken away from you. And, cuz like i said, Meteor is decoupling away from the view layer, it really isn’t that big of a deal–some people will continue to use Blaze, some the official React integration, others less official tools like Riot, Cycle, or Vue. You know. Because that will be the norm, it won’t be that big of a deal that the evolution of Blaze stopped.
I have run several such businesses over the years. What I’m saying is Meteor was always a cutting edge technology. It was always in a unique position though–because it distilled the cutting edge stuff for those of us that couldn’t be bothered combining it all ourselves. But don’t get it confused: meteor is for startups (willing to take risks to invent new experiences), not your traditional enterprise software business. It’s becoming that way as the ecosystem stabilizes. But it was always an inherent risk that we agreed to–which you must have forgotten–by taking something on like Meteor. WHY DID YOU FORGET? You forgot because Meteor did such a damn good job of making all the latest magic feel so solid. The lesson: don’t take things for granted.
Meteor is called Meteor? Why? You ever think about that. I don’t think I’ve ever read once a reason why it has this name. It’s called Meteor–and this is just my interpretation–because it has hit the software world so hard, um, like a Meteor. That’s the sort of impact its had! …But what does this metaphor really mean: it means it’s all about incorporating the latest and great tech. It’s not called “Rails”–if it was, then you could expect it to be a slow and steady chew chew train, and you’d be left in the dark ages like Ruby on Rails ultimately is.
Meteor in many ways has started to lag behind the rest of the NPM ecosystem. And real quick let me add this: NPM/Node/JS dictates the future of the web currently. Now, combine this lagging behind with the fact that Meteor really/ultimately has NOT had its time to shine yet. If Meteor can connect all the dots on the way to 2.0, it can finally get its spot in the sun. Meteor’s on their mission whether you like it or not. It’s up to you to see what there vision really is and make sound decisions or take risks based on that. If Meteor really nails the vision, it will integrate NPM/Webpack, rejoin the NPM community with the need no longer for custom packages (and the welcome additions of “code splitting”, a la Webpack); it will make the DB layer switchable (RethinkDB), just as its in the process of doing the view layer (React); and it will partake in the revolutions of more scalable subscriptions (GraphQL instead/in_addition_to LiveQuery); and it will partake in the revolutions of immutability (Redux, live code-reload, etc).
Just by rejoining the NPM community, and completing the unbundling process, Meteor will accomplish this. Everything else will be up to the NPM community to provide packages that you can plug in. I think we can do that, WHILE ALSO CONTINUING TO PROVIDE A “KICK STARTED AUTOMATED BUILD VERSION” for developers that don’t want to deal with that or are not experienced enough to deal with that, or just want to quickly prototype/hack, and deal with that later when its time to optimize.
But, lets ask someone from MDG: @sashko, am I wrong? Is something like not the vision for Meteor? I’ll summarize:
A) the full power of NPM, and mix-n-matching packages/layers
B) an automated kickstart version (which continues to be an option)
I think we are at a stage where we gotta focus on the unbundling and rejoining NPM. This is an area that we have not focusd on in a long while, and the key reason we have lagged behind the rest of NPM. We’ve always had the kickstart automated version. So once we rejoin NPM again, then we can circle back to the final quickstart version.
Well, I also ran into that feeling that it maybe wasn’t the best choice to use Meteor for my new projects. On my first Meteor project, I’ve just added some great packages like CollectionFS or Streamy to communicate between clients on the server. A nice choice and both worked great together - but only in my development environment. After deploying it to multiple servers, I just saw, that both weren’t ready for multiple instances and I needed to change a lot of stuff - that was a part were I really thought “Why the he** do they release packages that aren’t ready for a productional environment”.
I think the main problem of Meteors image is, that it delivers a false impression. If you read some articles about Meteor, they are all about “the simplicity” - but that is not right. It is easy to create a prototype, but it takes some research if you create an app with a lot of features and maybe that’s the point why some developers are disappointed - because Meteor isn’t all about simplicity. I remember my first thought when I’ve read about Meteor - “Cool, I can create reactive web applications and it seems to be very easy to scale them (meteor-cluster). Meteor uses Mongo, so I can also scale the database by Sharding and hey, there is a Cordova integration to build mobile apps and connect them to my web project - perfect!”. Then came reality: Sharding needs more research, Cordova integration has several bigger problems like the HCP crash.
But despite all disadvantages, I came to the point to realize, that there is no other framework at the moment, that give you all the features Meteor has. Meteor isn’t the perfect framework that runs “out of a box” without problems, but after some research and learning, you should be able to fix a lot of the common problems.
Let’s not forget that Meteor’s mostyl turn to dust, after hitting the world 
Jokes aside. We do have a start-up but are utterly confused still by the lack of Meteor direction… we have some way to go before the trajectory is a bit more predictable to be able to spend real dollars & euro’s…
Hard to be more proven than React. It’s literally used by more than a billion people every single day (i.e. Facebook and Instagram).
It’s not like MDG is moving towards Aurelia or one of the many other frameworks that don’t have a huge base already. They are putting their money on a horse that a lot of smart people think will be (and in some cases, already is) the future of web development. As Joel Spolsy says:
“Use things that are going to work great in two years.”
You won’t regret switching to React.
Are for and while loops easier to grasp than goto statements? At first glance, yes. People don’t like change, I get that. It takes a bit of work to learn a new paradigm, but would you rather live in a world where we are still using goto everywhere in our code? Many decades ago, there was a time when people like you made similar comments about the things we take for granted today. I understand the frustration, but I suggest that we take a lesson from history.
If you spend some time thinking about the potential benefits of moving towards an enforced componentized framework with “pure” components (pure in the functional programming sense), I think it’s pretty clear that it makes a lot of sense to go forth with React.
You might think you’re dealing with hipsters here, but I really don’t think so. React is a clear winner in the sense that jQuery had been a really clear winner from very early on. There was just as much vitriol and hatred when people started using jQuery in their code base as there was when people started doing meta programming or for-loops, etc.
That being said, if you don’t want to do React, no one is forcing you. Just realize that in a couple years, you’ll look like that guy who’s still using goto statements while everyone else is writing loops and other constructs (or better yet, mapping over lists).
Hilarious!
MDG isn’t the best at communicating their vision, and communicating in general. They’re a little standoffish. But in terms of executing and delivering, they are rock solid. Consider them the “strong silent type”.
…Now, me, I’m quite the opposite ;). So I could just be speaking for what I hope their vision is, but to me the vision for what it should be is absurdly clear. Unfortunately, it will mean lots of changes. But that said, if done right, I don’t see why they can’t let us hold on to the previous “vine” like monkeys until we are ready to adopt it. That’s what I’m about to showcase later today with Sideburns–we can have “the new hotness,” while maintaining past traditions.
I also think the reason they stay more silent than you might expect is not because they don’t also have the vision, but because–as we have seen with the Blaze/React debacle–it can be scary to application developers like ourselves to see such drastic changes before their solutions are also offered. Coming out about how they predicted the React situation would likely turn out was an adaptation of their usual pattern of behavior. Perhaps they would have been better served not saying anything until they had their final React solution to roll out. But at the same time, I think they were kinda pushed into a corner, given how vocal the Meteor community was about wanting answers, and given the fact that they were very late to addressing React. They are late on a bunch of things happening in the greater NPM community, but I think as the new module system rolls out (and Galaxy stabilizes), that will change overnight. I hope to see them firing on all cylinders with clear vision after the new module system comes out.
I’d also add they’ve always been clear of vision–software just takes time to execute. Especially when they’ve been enchained by their non-NPM walled garden that once served them. Bottom line: there was no Webpack until recently. They basically invented the “isomorphic build.” Webpack still doesn’t have solutions for “full stack isomorphic packages” like Meteor does today and has had since inception. If Meteor was to embrace Webpack–which I think they should–they would have to fork it (and hopefully merge back) solutions for building packages that serve code to both the client and server. Webpack has no package-level way of specifying what’s served to the client and what’s on the server. …So once we have modules, then we can take on Webpack more seriously. And then once we have that, we can hopefully go pure NPM. If we went “pure NPM” now, well, your application and packages wouldn’t build. There are solutions by @SkinnyGeek1010 and @jedwards, but I personally have yet to try them, so I can’t comment, but my guess is there is still major challenges there. Perhaps, I’m wrong, and the only challenge is that it has no “kickstart option” and therefore requires developers to have full knowledge of Webpack, and go through the tedium of importing code. Meteor has always been about offering that “kickstart” option that even novice developers can get up and running with. They can’t and shouldn’t abandon that. They just need to be able to offer the super pro route in addition, as a natural progression when you (or your app) is ready for it. So if https://github.com/jedwards1211/meteor-webpack-react is feature complete today, minus the “kickstart” option–i dont even know what to say; that’s an interesting turn of events. I.e. being able to run all of Meteor on NPM proper. That means the future is already here. Either way, we’ll want Meteor to offer that as a natural progression from the auto-bundled “kickstart” approach we’ve all come to know and love–rather than, a kinda big leap you gotta take.
note: this is pretty much a summary of a bunch of talk I’ve read in Github issues on their work on modules (by @benjamin) and David Greenspan’s “Webpack” synopsis:
You are making me nervous, man. 
Is there any good documentation out there about what might happen if you go productive - and how to prevent these issues during development? It would be a nightmare if deploying the app would take as much time as developing it. And no, I don’t have the cash for a Galaxy-hosted environment ATM.
EDIT: Just to be fair to the owners of CollectionFS: At least they state clearly that their code is not ready for prime-time yet.
you saw they released the “Developer Edition” today. get on the waiting list. Price is looking good, and you can start out with only one 512mb instance.
Otherwise, I’ve had great successes with MUP, and @arunoda’s cluster package + compose.io.
Yes, I already put myself on the waiting list 
And MUP will definitely be the next thing I will be looking into.
@faceyspacey But how did you sync, for example, all Meteor instances to Streamy? I know that @arunoda used a meteor-cluster with his deprecated plugin meteor-streams (http://arunoda.github.io/meteor-streams/scaling-support.html).
@waldgeist We’ve used CollectionFS with their GridFS plugin. As you can see on their issues list, a lot of users run into server crashes when they use multiple instances. I think their S3 plugin has/had the same issue. At the moment we’ve decided to switch all file uploads over to a seperate service, based on Sails.js. There we use the ddp-login plugin to authenticate a user (by login token).
A missing file upload feature in the core of Meteor is IMHO a very big disadvantage, because nearly every other framework has a simple method to handle such uploads - and to be real - today it is a standard feature in nearly every application. Maybe they didn’t implemented it yet because it isn’t recommended to stream static files via Meteor.
I’ve never used Streamy, but that page basically says to use meteor-cluster. …Like you said though, the project is inactive/deprecated. Do you really need that though? If Mongo (which you can get a lot of mileage with using compose.io + a cluster of stateless webservers) doesn’t offer you the scalability you need for lots of messages, there’s also a Redis integration. I haven’t used it though.
Stepping away from LiveQuery is likely going to enter the Meteor world as GraphQL subscriptions pave a different path, where incoming state can trigger subscription behavior without the need for heavy LiveQuery oplog tailing, i.e. prior to writes to the database.
So it all depends on how much activity you expect on day 1. Are you building something for the NFL or a Hollywood studio, or launching a startup that you hope to rise to the top [of its respective industry]. You may get all the mileage you need in the early days just observing mongo queries from the client, i.e. 1-10 of the most recent rows. I’ve added chat to a lot of middle-tier-usage apps that way… …And by the time you do reach these scalability needs, non-LiveQuery solutions may have progressed–there’s a lot going on right now toward that end. MDG is very aware of the scalability challenges of LiveQuery + Mongo.
So the question is: “are you prematurely over-engineering?”
Sergio, why is this all or nothing? Can’t you just use Meteor in the projects where it makes sense, Rails where Rails makes sense, and whatever else you need when you need it? Q42 doesn’t claim to use Meteor on everything. We use it when the developers, the work and the audience overlap. Like with every technology.
Oh yes, I know the GridFS plugin. I had so many issues implementing it that I switched to edgee:slingshot, which was a breeze compared to GridFS.
I am using this for uploads directly from the server to S3, because this is beyond the scope of slingshot. Do the scaling issues occur in this case as well? Would try Knox then.
Is that a Sails.js plugin, or a node.js plugin?
Yes, that’s so true! I never understood why this is not available. And things get work once you add Cordova to the picture.