Hacker News Reader

Comment by sanderjd | Hacker News Reader

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.

View on HN

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

[1] https://github.com/Simperium/simperium-ios

[2] https://github.com/Simperium/simperium-android

[3] https://github.com/Simperium/simperium-js

[4] https://github.com/Simperium/simperium-python

Neat. Thanks for the pointer!

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!

Reply on news.ycombinator.com