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.
It's completely different from ES6, it's a full-stack framework, so it does SO much more than just a front-end framework.
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.
Is DDP or Meteor really needed though? Couldn't you easily set this up with RethinkDB using its Changefeeds killer feature for real-time + socket.io along with whatever other library/frameworks you want to use without ever touching Meteor?
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.
If you're willing to wait for a client-server round trip to visibly see your changes, then sure. Otherwise, you'll need a way to temporarily (optimistically) change your in-browser data model with the updates while waiting for the server to commit your changes, then figure out a way to reconcile the server commit of v2 while you might have done v3 on the client in the meantime... Optimistic updates are not at all trivial. Meteor has a ton of code that basically runs an in-RAM version of MongoDB and keeps it in sync with the server.
You'll still miss out on the client side optimistic updates.
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've not used Meteor, but I understand one of its big selling points is 'optimistic UI', i.e. it alters models locally when changes are made, and syncs those changes with the server in the background, only changing the local model back again on failure to sync with the server.
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.
You ask a really good question. With all the myriad javascript libraries coming out weekly, you'd think we would all know of four different optimistic synch libraries off the tops of our heads, but I don't think I've seen any. Perhaps that's because in order to get it to work, Meteor has a bunch of code that (I think) watches Mongo's write-ahead-log, so you can't just make a front-end library for it. I think this is also why SQL support has been slow to come.
There's Simperium (disclaimer: I was a cofounder, YC S10). It's powering optimistic sync for millions of users of Simplenote and WordPress.com. It has JavaScript[1] and Python[2] libs, but its strength is iOS[3] and Android[4].
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).
I had a good look for a library that does this for the app I'm currently working on, before giving up and creating a custom solution myself. My implementation is very much custom-fitted to my particular backend api and the way I'm rendering the view layer with React.
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.
That's basically my take on it, and we also have a bunch of custom code to do similar things piecemeal, but it doesn't work very well and I envy Meteor's solution, while remaining unprepared to jump onto the framework in its entirety. But lots of "really difficult" things have been accomplished in the past, so I'm still hoping to come across a "general, flexible, tech agnostic solution to this problem" at some point!
The web components spec is starting to look like a huge mess in comparison with modern JS framework component models. I think it's unlikely web components will much traction as a first tier approach to application development.
Sure. Meteor can be used to implement your backend, frontend, or both frontend & backend. Web components are a frontend concept only [from what I understand]. Meteor's frontend code can "bind" to your backend, and render real time data updates.... while web components have no concept of "backend" at all.
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.
