All requests go to a REST API which only returns head responses, and shoves the actual data response onto a queue. The websocket server reads off the queue and publishes the response to connected clients.
On the client side it's all actions and dispatchers and react components. Keep meaning to write an in depth blog post about that when I get the time.
This reads very similar to how IMAP is defined (it's not a request/response protocol).
And Websocket seems like an overcomplication of the system as you need a WS-compatible server and broker, it would probably be simpler to use SSE. See http://matthiasnehlsen.com/blog/2013/06/23/angularjs-and-pla... for an example of SSE+occasional HTTP calls.
The big difference, of course, is that such a system is not really offlinable, the application is basically frozen as soon as the connection is lost.
 even if MSIE doesn't support them, they can be polyfilled even in IE7 and old android browsers
 plus SSE has native support for server-configured reconnection timeout, event-ids and custom event types, all that in an ASCII-based format
I'm not _as_ worried about offlinable, to be honest. This post just tickled that part of my brain that had been thinking about React.
Yeah SSE is one of the most interesting APIs people have never heard about, everybody jumped on WS but for many use cases SSE is more than sufficient, much simpler to deploy and use and a much simpler upgrade path from polling.
Webstorage has excellent browser support but isn't utilised enough (http://caniuse.com/#search=webstorage)
--EDIT-- sorry @untog, I replied to the wrong comment and deleted before as you replied.
Also - these fallbacks are not exactly swappable. Its like swapping from a Database to a Filesystem as a fallback. Difficult to abstract into a single library/api.
And you still potentially leave out IE users if those are your options (depending on your IndexedDB needs).
IndexedDB to localStorage fallback might work - but again might not be an easy API abstraction.
Web SQL may be "deprecated," but it's unlikely to be dropped by Apple or Google, since so many mobile web apps depend on it. Even the mobile version of Gmail uses Web SQL.
That's isn't much of a problem with JSON.strigify and JSON.strigify.
I've created a small library which is making the html5 manifest much easier to work with so I can put http headers like commands inside it. The client is checking with an interval to update the app and there is a built-in loading bar to show the download. This supports also an additional client-side api to make things easier.
Here is a gist of how it looks like currently : https://gist.github.com/alex-min/1bbc304ad9b96bdf5c96
I think I could see if I can open-source it if that's interesting for some people.
But this library seems really nice, I will have a look since the synchronization of objects seems really well done. (from the demo page).
That flexibility is paid by (1) implementing Lamport timestamps and by (2) limited use of version vectors (on handshake). ShareJS versions are linear, for example, but those linear versions are specific to a replica, as far as I can tell. In OT, version 3 here and version 3 there are possibly different.
CRDT/CT is generally easier to reason about than OT, esp. considering various non-standard situations and implications. That is mostly because CRDT (this flavor) employs "partially ordered log of immutable operations" while OT operations are mutable. That is the formal difference.
Lamport timestamps are "guaranteed" to be unique.
* plain text
* rich text
* by-column Last-Write-Wins objects
...and many other useful things.
Also, we did a RichText implementation for one-$10bn-company-that-forbids-to-mention-its-name-too-often. I did not publish that yet.