So, to put it glibly, the only people who will use Meteor for large-scale projects are those who have no choice?

No, not at all. It's the other way around, really. Those who don't use Meteor for their projects may not be able to without trashing existing codebases.

What I'm hearing is that Meteor doesn't play well with others and that you should make the decision to go with Meteor carefully since changing your mind later will require a ground-up refactor.

This is pretty much my experience as someone who started working on a project where the lead dev had decided to use Meteor and then quit leaving a wonky prototype with "reactive data", poor performance and missing functionality.

Now, some would say "it's not Meteors fault the UI wasn't made well!" and then I'd reply "sure, but if Meteor didn't encourage (and it seems, require) tight coupling of the data access and presentation layers, then maybe we wouldn't have spent the last 3 weeks rebuilding the entire app from the ground up just to add some missing functionality and fix UI bugs".

Honestly, I really can't figure out the lack criticism I see of Meteor around here. All these comments to congratulate on an arbitrary step in version number? I see other articles of accomplishment with a fraction of the positive encouragement and many times the criticisms. Is there a silent majority, or did I spend the last few months being underwhelmed by Meteor because I'm missing something?

Meteor embodies, for me, a tool that makes things 'easy', rather than one that makes things 'simple'.

http://www.infoq.com/presentations/Simple-Made-Easy

Anyways, that's just one developers experience and opinion, take if for whatever you feel it's worth.

Meteor does make things easier, by making things simpler.

It is much simpler dealing with Meteor's API's then working with documentation from 3 or 4 different frameworks that you need to accomplish the same kind of stuff Meteor does.

Meteor gives you a set of clean coherent APIS to work with to get stuff done.

Meteor doesn't require tight coupling between data access and presentation layers. Personally I use meteor with react.

A lot of criticism of "new shiny tech" gets downvoted/flagged on HN so people don't even bother anymore, while another useless library in Go/Javascript gets pushed to the top of the front page.

No, the people who use meteor for big projects are those that started using it when they started it as a small project.

Because if you started a small project in something else, it is not easy to change it to Metero later.

What he said was quite clear.

Quite the opposite. Those who can choose anything choose Meteor.

Actually, you can use Meteor as a frontend-only framework. Just have the Meteor server be the client for a standard REST API. I've built an app using this approach.

So is it a PaaS like Google App Engine? Is it just an MVC like angular or ember?

No, it's a full-stack framework, using Node.js on the server and sending down a client app bundle containing all HTML templates and JS. The client and server then communicate exclusively with JSON through a purpose-invented pubsub WebSockets/SockJS protocol they call DDP. The client has a simulated MongoDB database and thus much of the API is isomorphic, so the client will simulate the server's code while it awaits the actual server response. Client changes to the data are immediately effected in the browser DB, while the change is authorized on the server, synced to other server instances with MongoDB oplog, and then pushed down to all clients subscribed to that data. The templating engine is then reactively informed of the data change, and the DOM is updated at the lowest level possible such as modifying an individual text node.

Thanks for this info.

Does it have to use Node.js on the server can the client side framework work with any server side JSON service?

You need to be running the Node.js Meteor application. The client relies on DDP rather than REST and right now Meteor is the only server framework using DDP. There is, however, an isomorphic HTTP library which makes it easy to communicate with third party REST APIs on both the client and server. It is also easy to create REST endpoints for your Meteor collections, so that third party services which don't support DDP can communicate with your app.

It is very possible to use other client side frameworks such as Angular or Polymer, rather than just using Meteor's Blaze UI engine. However I find that Blaze's Template<--Helper<--Data<--Event system is extremely easy to understand and reason about.

Edit: Actually, they do seem to have a decoupled version of the Blaze UI that you could use just for your reactive DOM code and hook into a REST API. You just won't get any of the server-dependent features like full-stack automated data synchronization, hot-reload, live CSS injection, or Meteor's build chain. You just get a simple reactive template/helper/events system. http://meteor.github.io/blaze/

Thanks!

I think it has to be Node.js all the way down.

Spot-on explanation, wish I could be so coherent when trying to explain Meteor to other people.

It seems like too much magic until you've been exposed to it a bit. It's actually pretty simple to visualize what's going on under the hood, but it takes a bit to click. Reading the DDP spec and the tracker package definitely helped me grasp the concepts. The new subprojects page is also great at explaining the major Meteor components: https://www.meteor.com/projects

It is not a PaaS, it is a framework that goes a bit further than previous frameworks. Angular and ember really just work for front-end code.

Meteor spans both the front-end and back-end to offer a seamless API experience when building your application.

It's basically something like Java Server Face in javascript,which can be a good and a bad idea...