

Is this the death of REST? - contingencies
http://kripken.github.io/sql.js/test/demo.html

======
contingencies
(Confession: the title was _sqlite in js [673,971 bytes gzipped; via
emscripten]_ but nobody cared, so I made it more linkbaity.)

So we've got sqlite in JS now. It's a little heavy, but that's amazing for
some applications. Meanwhile, there's the W3C's IndexedDB under proposal:

[http://www.w3.org/TR/IndexedDB/](http://www.w3.org/TR/IndexedDB/)

[https://developer.mozilla.org/en-
US/docs/IndexedDB](https://developer.mozilla.org/en-US/docs/IndexedDB)

... optionally with
[https://github.com/axemclion/IndexedDBShim](https://github.com/axemclion/IndexedDBShim)
for greater browser reach.

(I really do wonder how the W3C justified IndexedDB given SQLite's excellent
codebase and small size? I guess they mainly wanted event hooks because I
can't see any other impressive features.)

So, how long until we see an implementation of `rsync` for some of these
things? Why bother with developing complex manual-integration APIs if you can
just perform a gzipped batch-sync of your client-exposed DB portion right down
to the client app, and offload all that server processing and round-trip
overhead, SQL injection risk, etc.?

Potentially fun project for someone else: learn IndexedDB + LLVM + asm.js +
emscripten + rsync batch mode source + generalized javascript serialization +
sync the crap out of some DB's over slow links + benchmark
performance/reliability/integration implementation speed changes vs. current
era REST APIs. (Alternatively,
[https://github.com/ttezel/anchor](https://github.com/ttezel/anchor) appears
to be an rsync implementation in node.js)

Perhaps for mobile applications and other rich client scenarios (browser
games, data-heavy financial or monitoring frontends, etc.) REST is now on the
way out.

