
Web SQL Database: In Memoriam - daleharvey
http://nolanlawson.com/2014/04/26/web-sql-database-in-memoriam/
======
actsasbuffoon
The great thing is that we're on the verge of not needing Web SQL anymore.
sql.js
([https://github.com/kripken/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.

~~~
ken47
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.

~~~
jwise0
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!

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

~~~
pornel
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 })

~~~
nolanl
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.

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

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

~~~
nolanl
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](https://gist.github.com/nolanlawson/8330172).

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

~~~
rjd
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.

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

~~~
yogo
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.

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

~~~
mccr8
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](https://bugzilla.mozilla.org/show_bug.cgi?id=2056)

------
MatthewPhillips
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/](http://gazeljs.org/)

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

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

Perl is obsolete? LOLz.

