They just keep on delivering on out-of-the-box functionality, compatibility with 3rd party libs, and more importantly - on a very solid architecture for real-time transport by guys who really know what they're doing.
Kudos everyone.
The platform is not just for playing around anymore, it has matured really well. See the case studies[1] - I, for example, love Hansoft X[2].
I think I would feel frustrated to have to go back to any other framework. Meteor is what web-development should be like. I'm not sure if Meteor is going to be THE platform everyone is going to use, but it definitely is completely changing the game and I suspect web-developers will be adopting the Meteor ethos.
[1] https://www.meteor.com/case-studies/build-apps-with-meteor [2] https://hansoftx.com/
I don't think either that Meteor is going to become de facto platform for all web development, but it's definitely going to be one of the main ones along with Angular, React and Rails.
It's interesting also that people always talk about Rails but don't mention JSP and .NET, which I think are actually a lot more popular last time I looked around. I guess it depends on who you ask.
I feel like JavaScript is in a sweet spot right now because it has the inherent advantage of being the _only_ language you can run inside a browser, so you can do things with it that would be very hard or complicated in other languages.
And, though I know this has been said before, it bears repeating: most developers who deal with data on a regular basis are best advised to go ahead and get comfortable with SQL. So far, it is BY FAR the best solution to the great majority of data-storage-and-retrieval use cases. I'm no expert, tis true, but I don't see JSON objects replacing SQL any time soon.
So, yes: as soon as Meteor includes official support for one of the SQL platforms, I'm all over it. It seems very promising, for those of us not locked in a death-rattle of foaming, red-faced JavaScript hatred.
I wish I had a more educated answer (guess?), since this is all just anecdata.
Actually, they have: https://reactioncommerce.com/
Meteor has been perfect for me. It works, I can easily integrate with it via the Mongo back-end, and the prototyping is super-fast. For the kinds of apps that I build (very industry specific apps for retail) I don't really have to worry about scaling to thousands of users, which means that Meteor isn't just a toy in my world. And even if I did have to scale, everything about the Meteor framework indicates that scaling Meteor is no different than scaling any other Node app.
When Postgres support comes, (its in the works) I'll be using this thing for everything.
I don't want to be the first person attacking a completely new class of scaling problems using a proprietary tech stack that I may or may not have the ability to control.
The other piece is the meteor stack is designed to be hosted by meteor. Sure, you can, in theory, run everything yourself - but I haven't seen good case studies of that. What do you do when your app blows up and suddenly the hosting costs of meteor is too much of an overhead?
I use Digital Ocean with MUP and it works great with minimal efforts.
What kind of load does that app you host on digital ocean have?
Edit: I'm not at all suggesting that isn't possible to self host a meteor app, I am saying that I don't know what the "beaten path" is for other companies/apps/products that have self hosted a meteor app to a significant scale.
As the lead developer of Sandstorm.io, I have deployed Meteor:
* As the Sandstorm front-end, where Sandstorm is designed to be installed by end users on their own machines.
* As apps that run on Sandstorm, and are designed to be extremely fine-grained (each app instance handling a tiny amount of data, e.g. a single document).
* As oasis.sandstorm.io, a highly-scalable centralized Sandstorm host.
* As apps.sandstorm.io, a fairly mundane use case (whereas Sandstorm is, comparatively, highly unusual).
I would argue that Meteor is not at all designed for Meteor hosting. Rather, Meteor is designed such that anyone wanting to build a PaaS around it will have a much easier time doing so than they will with just about any other environment. On Sandstorm, we find Meteor apps much easier to package than anything else, because the Meteor tools will output a self-contained app bundle that operates in a consistent fashion for all apps -- thus allowing us to write a common packaging tool that works with all Meteor apps. Other stacks are comparatively much more fiddly.
I would expect Meteor's hosting will turn out to be the best way to run Meteor apps primarily because they have kick-ass engineers there who will build an awesome product (disclosure: I know several of them), not because they've biased the framework in their favor.
What does that mean exactly? I admit, I only kind of know what sandstorm does from it's marketing page (looks like it offers VM's in a more user friendly way with an emphasis on security)
In what way does Meteor allow you to produce quicker or more efficiently than if you went with any standard linux stack?
Try installing Wekan, which is a Meteor-based app.
The thing that makes Meteor easier for us is, as I said, the meteor tools have a command "meteor build" which gathers all of the app's code and package dependencies and puts them into a self-contained directory tree with a start script that is executed the same way regardless of the app. This makes it easy for us to build a tool which turns any Meteor app into a Sandstorm package because the input is in a well-defined, self-contained format.
We are, of course, building tools for other stacks as well. It just takes more work.
I think inevitably the meteor team will bring this into core, or something similar, and we will be able to have our mix of atmosphere and non libraries.
Iron-Router was the lead for a while.
I don't think these should necessarily be in core, but here is my list of pretty much always-installed modules:
stevezhu:lodash iron:router meteorhacks:npm meteorhacks:async aldeed:collection2 aldeed:autoform aldeed:tabular xolvio:cucumber yogiben:admin