Web SQL Database: In Memoriam | Hacker News Reader

Web SQL Database: In Memoriam

nolanlawson.com

104 pointsdaleharvey21 comments

The great thing is that we're on the verge of not needing Web SQL anymore. sql.js (https://github.com/kripken/sql.js) is SQLite compiled to JS (via Emscripten). It can do everything you'd normally do with SQLite. You can take the db and serialize it down into a format that can be stored in local storage, and rehydrate the DB from that when a user returns to your site.

The only thing preventing this from being practical is that sql.js weighs in at around 2MB. Still, there are caching mechanisms that could get around that issue.

I think it's fantastic that we've reached the point where we don't need databases baked into our browsers. All we need is fast JS engines (which we have) and a dumb data store (which we have), and we can provide our own client side databases.

I've used both sql.js and WebSQL. Sql.js will get the job done in a lot of cases, but it is not a perfect substitute. Sql.js's performance is an order of a magnitude worse than WebSQL when put under heavy load (this likely has more to do with ASM vs true native code than Sql.js in particular). Particularly, sql.js starts to stutter at a far lower query load than WebSQL for a given machine. Furthermore, Sql.js uses sqlite3_exec() under the hood, which means that all results get converted to strings, regardless of the underlying type of the column. And finally, effective memory capacities are not the same.

Yes, I just wrote a small app around sql.js, and I was surprised at how poorly it performed. I was expecting to be within a factor of three of native, but I'm seeing performance down by an order of magnitude or so. The sql.js page alludes to bugs open in Firefox and Chrome for these issues; I imagine they'll shake out over time, but it's certainly not a buttery smooth experience just yet. Even still, it certainly works better than the alternatives!

I suppose it's just like your regular OS. Files, but no built-in databases.

Though it's a shame to need a 2MB database library to have a practical datastore.

It isnt needed in order to have a practical datastore, indexeddb is somewhat ugly but very practical, wrapper libraries on it are generally fairly small and can be very usable / are very practical.

It is needed to get a a particular database running, but I agree its awesome that the capabilities of the web are improving to the point this is possible.

It's unfortunate most of this was debated at the beginning of all the hype around NoSQL data stores.

It would be some work, but still be relatively trivial to build a query spec, probably based off of SQL 92, and a basic type system spec (Strings, numbers, and dates are the bulk of it), and then an implementation of everything else.

Facebook did it with Presto, although they haven't finished the DML part of it.

Reading the emails, I get the feeling most of the people involved didn't have as much experience with databases as they probably should have in order to make a truly informed decision.

The problem is that all pages aren't written to the spec, they're written to work with implementations.

When there's only one implementation (that authors care about), then every quirk, bug and accidental misfeature can be depended upon, and SQLite has plenty of those ("FLOATING POINT" parsed as "INT", magic of ROWID, the lax type system even more forgiving than PHP, etc.)

If there was another implementation then lack of overlap in quirks/bugs would prevent authors from depending on them (e.g. if you wrote something stupid then it'd work in one browser, but not the other).

ASCII venn diagram of 2 implementations:

   { bugs1 ( usable standard } bugs2 )

ASCII venn diagram of all browsers just shipping same Sqlite:

   {( usable: standard and all bugs })

That's a good point, and one I could have added to the post. There are bugs in Web SQL, but they're largely the same on both Chrome and Safari. IndexedDB is trickier, because the bugs are all different between Firefox, IE, and Chrome. Again, another situation where libraries can help out.

Although in general, it's sad that the "independent implementations" mantra basically guarantees a lack of consistency across browsers. It's like we only have a choice between "pointing to a pile of C code" or ending up with a pile of browser bugs. Maybe the W3C could write acceptance tests to go alongside the specs.

> Maybe the W3C could write acceptance tests to go alongside the specs.

Like these? :) https://github.com/w3c/web-platform-tests

Heh, I learned a thing about a thing! :) Curious to know how so many quirks slipped through, though. Maybe I should do a PR on the tests for bugs that the browser vendors might not know about, e.g. https://gist.github.com/nolanlawson/8330172.

They could have defined a subset of SQLite which you could implement without needing SQLite.

But if everyone used the same buggy implementations there would still be a problem. Web developers usually write for the implementation, not the spec.

WebSQL is remarkably simple to use, works on the most popular browsers on mobile and desktop, and gives you the power of SQL. In contrast, IME indexed db felt like pulling teeth. The discussions seem to suggest that institutional intransigence by Mozilla pushed the internet back a step. (And yes, SQLite + Emscripten is significantly slower than websql on chrome and iOS Safari)

From a personal perspective I stopped building HTML web apps after I started to transition my WebSQL apps to IndexedDB. I really really disliked the experience (messy code/overhead) and haven't had any desire to write another with a client side DB again. The bright side for is however it drove me to learn iOS and Android development... not such a great day for the web though as I suspect my experience isn't unique.

As always, there are some problems IndexedDB document stores solve well, and others that SQL is really well suited for, and I think it's great to have both options. What sucks is when people say "Sure, we'll support that there is more than one way to do this (TMTOWTDI), as long as you recognize that my way is the right way in almost all foreseeable cases, so we'll build the tool this way". That statement is rarely correct, especially when making a browser capability. (Yes, I know, trying to disprove a generalization with a generalization isn't very persuasive. Oh well.)

I read all the concerns (it's a standard built around sqllite, and who wants that?!?!, etc.) and I still sigh a sigh of disappointment that it's come to this. I know, Web SQL isn't going away, as the author points out, but it will be a 2nd class citizen for the foreseeable future, and that's just a missed opportunity, imho.

Exactly they both have scenarios that they work very well for just like you have with the server-side SQL RDBMS and the NoSQL ones. IndexedDB is fine for simpler apps or apps where there isn't a real need for joining, grouping and ordering the records in a very flexible way.

Web SQL is definitely dead in native Chrome apps. It was never born actually given IndexedDB was the only solution that was pushed.

The flip-side is that IndexedDB being an independent spec means they are able to extend it in ways that wouldn't be possible with WebSQL. For example, in IndexedDB you can store arbitrary Blobs as values. This means you could store an HD movie if you wanted. With WebSQL you had to base64 encode blobs to store them.

I think this articles kicks on one key thing that explains the lack of enthusiasm around IndexedDB... people primarily want a database on mobile. And iPhone doesn't support IndexedDB yet, that is enough to kill it.

WebSQL yet another web spec that the Mozilla Foundation won't implement because of "problems". There are a few bits of CSS that I would love to use all over the web, like "display: run-in", but Gecko is the only holdout.

It sounds like Blink and WebKit are actually removing display:run-in, according to the Gecko bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=2056

Shamless plug: My (now quite old) library Gazel puts a Redis-like API on top of IndexedDB making it pleasant to use: http://gazeljs.org/

> Often in the tech industry we’re too quick to eviscerate some recently-obsoleted technology (Flash, SVN, Perl)

Perl is obsolete? LOLz.

Reply on news.ycombinator.com