When ES6 and web components come out, are we even going to need frameworks like Meteor? It seems like all of the advantages of MVC frameworks go away once you can create controllers and models in native Javascript and views in native HTML.
Meteor's main selling point is the reactivity; you can call `Books.insert({ name: "test" });` on the client, in-browser and it then updates the UI optimistically, updates the DB on the server AND propagates the change to all other clients, which in turn updates their UIs. All with one line of code.
Take a look at DDP, one of the core building-blocks of Meteor: https://www.meteor.com/ddp
curl https://install.meteor.com/ | sh
so much quicker (in the short term and long term) than reading a myriad of tutorials and then bashing my head against this configuration of several products for multiple weeks to get what Meteor provides as part of a single maintained and updated system.
(I work at Meteor)
I think the main benefit of Meteor is not that it's impossible to do what it does with other libraries/frameworks, but how easy it makes those things for you.
I don't know if this can be (or has been) extracted to a separate library or if this is part of the web components spec, but its something that's pretty nice to have baked into the framework.
In fact the only reason I'm not using Meteor now is that it's still got a hard dependency on Mongo. I was disappointed to see that SQL support has not begun to come in yet with this update. Once SQL support is there, I will definitely be looking at using Meteor, particularly now it's got first-class React support.
I think a large part of the reason such standalone libraries might not exist yet, is that it's really difficult to make a general, flexible, tech agnostic solution to this problem - as you've highlighted this is probably why Meteor's implementation is so tightly coupled with Mongo and why SQL integration is taking a while (assuming, surely, it must be a pretty high-priority feature on their roadmap).
In other words such a library is likely to be so prescriptive on how the rest of the stack, particularly the backend, fits around it that it only really makes sense as part of a full-stack framework, or at the very least a prescriptive full-stack architecture.
The team focused on internal use though, and hasn't had a chance to open source the backend and flesh out the web side of things. I hope they get a chance to do another iteration (we were bought by Automattic/WordPress and I'm no longer there).
[1] https://github.com/Simperium/simperium-ios
[2] https://github.com/Simperium/simperium-android
There could also be a desire to wrap multiple web components into an Angular directive, or wrap multiple Angular directives into a meteor module, etc.