Meteor just hit 1.0 and is not the type of framework you can just start including in your stack.
You really have to build a meteor app from the ground up, so it is hard for established tech companies to get into Meteor when they already have spent years coding on another stack.
As new startups who use Meteor grow you will see those large-scale projects come about.
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'.
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.
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.
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.
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.
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/
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
You really have to build a meteor app from the ground up, so it is hard for established tech companies to get into Meteor when they already have spent years coding on another stack.
As new startups who use Meteor grow you will see those large-scale projects come about.