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!
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.