
W3C Working Group Just Killed Web SQL Database - Udo
http://www.w3.org/TR/webdatabase/
======
halo
Probably a good thing. The most complex part of Web SQL amounted to "Whatever
SQLite implements", neither Mozilla nor Microsoft supported it making the
standard effectively irrelevent, and I remain thoroughly unconvinced that
providing an extremely thin JavaScript API to an SQL-driven database is an
elegant solution to this particular problem.

Presumably the W3C have decided to favour IndexedDB instead, which solves many
of the same problems in a much more elegant, simple and well-specified
fashion.

~~~
ergo98
_The most complex part of Web SQL effectively amounted to "Whatever SQLite
implemented"_

Which is one of the most tested, most utilized, most known pieces of code used
among modern software. Saying "reference it" is entirely rational. And really
the ludicrous notion that documenting its behaviors is unfathomably difficult
is so asinine that it demolishes that line of argument.

 _neither Mozilla nor Microsoft supported it_

Microsoft doesn't REALLY support either: Does IE9 have IndexedDB? Not that I'm
aware of.

Microsoft's angle regarding Web Databases was nothing more than "I don't
know...that looks mighty uppity for a web app..."

Mozilla is taking a very myopic, "high-road" approach that is similar to, and
less justifiable, the whole h.264 debacle: Everyone loses, but someone gets to
hold their head up high.

Further, Chrome, Safari, Opera, other...none of them support IndexedDB, so as
a standard it is effectively irrelevant.

 _Presumably the W3C have decided to favour IndexedDB instead, which solves
many of the same problems in a much more elegant, simple and well-specified
fashion._

Ha ha ha!

The IndexedDB spec right now has _incredible_ gaps that make it close to
useless. The braintrust at Mozilla that are responsible for it can't stop
themselves from saying "CouchDB" long enough to actually work on it, it seems.

I think they got caught up in the whole NoSQL thing. So much so that they now
seriously advocate that libraries should pop up inefficiently implementing SQL
on top of IndexedDB, which is just saddening.

But aside from that, rah!

~~~
halo
The truth is the reason they pointed to SQLite is because the proposed API was
so obscenely complicated that it was easier to point to a reference
implementation than to accurately specify a standard, which points to a rather
fundamental problem with the proposed standard: SQL is too damn complicated,
and embedding it in browsers is a bad idea.

For a web standard to succeed, you need either Mozilla or Microsoft support,
preferably both. They have 75% of the browser market between them, so without
either any standard is dead on arrival. Chrome, Safari and Opera individually
do not have enough marketshare to be a significant influence on the takeup of
web standards and still follow in the footsteps of the others. Incidentally,
Chrome does support IndexedDB ([http://peter.sh/2010/10/indexeddb-
milestone-8-es5-strict-mod...](http://peter.sh/2010/10/indexeddb-
milestone-8-es5-strict-mode-and-progress-on-print-preview/)).

Mozilla have made it clear they are supporting IndexedDB and not WebSQL.
Microsoft have publicly posted remarks of support of IndexedDB on the IE blog
([http://blogs.msdn.com/b/ie/archive/2010/03/09/working-
with-t...](http://blogs.msdn.com/b/ie/archive/2010/03/09/working-with-the-
html5-community.aspx)) and Pablo Castro, an architect involved with web
standards has publicly favoured IndexedDB over WebSQL
([http://blogs.msdn.com/b/pablo/archive/2010/01/04/html5-does-...](http://blogs.msdn.com/b/pablo/archive/2010/01/04/html5-does-
databases.aspx)). It's not always easy to judge the inner workings of
Microsoft, but I think it's a pretty strong hint as to what they are working
on.

The IndexedDB spec seems relatively well-specified to me, and much more
detailed than the WebSQL spec. Incidentally, the original authorship of
WebSimpleDB was Nikunj Mehta, who was an Oracle employee at the time. The
standard didn't originally come from any "braintrust at Mozilla".

~~~
drivebyacct2
Why not just use SQLite? Write a small wrapper around it to isolate each
website off on it's own database or set of databases. Each site corresponds to
a SQLite user with a password that ONLY the browser knows.

~~~
sid0
Because if everyone used SQLite there would be no second implementation, which
is something that is _necessary_ for a proposed standard to become an actual
standard.

~~~
Groxx
I believe you, especially as it makes a number of lines I've heard around this
make more sense... but why? Especially in this case, where there _is_ a
standard and it's already been implemented by several? Is it just pedantry
because they don't get to call the shots?

~~~
sid0
> where there is a standard

There is no standard. There is a _proposed_ standard, but it's failed because
it didn't have multiple implementations.

> and it's already been implemented by several

No, it has exactly one implementation: SQLite. SQLite-in-Safari and SQLite-in-
Chrome obviously don't count as different implementations.

~~~
Groxx
It has one implementation implemented identically in more than one browser.
SQLite. Which _is_ a standard _with_ an implementation to compare against.

Anyway.

Yes, there is only one implementation, one standard, one non-W3C-spec. Why
does it matter to them that there's no competing spec, when they _could_ just
support something that is already out there, and can be solved by pointing to
<http://www.sqlite.org/docs.html> ? The API for accessing it is mindlessly
simple and small, documenting _that_ would take a day at worst.

It seems they're trying to run it into the ground _because they don't control
it_ , because it didn't go through their proper procedure, whereby it must
have a competitor.

Why? In what way is this helpful? And if they're not being helpful, what's
their purpose? To be dogmatic and prevent good ideas they didn't come up with
from spreading?

\---

edit:

> _The World Wide Web Consortium (W3C) is an international community where
> Member organizations, a full-time staff, and the public work together to
> develop Web standards. Led by Web inventor Tim Berners-Lee and CEO Jeffrey
> Jaffe, W3C's mission is to lead the Web to its full potential. Contact W3C
> for more information._ (from <http://www.w3.org/Consortium/>)

How does trying to prevent it aid in "lead[ing] the Web to its full
potential"?

~~~
sid0
_Why does it matter to them that there's no competing spec_

Because _ALL_ web standards are standards only because of the fact that there
are _MULTIPLE_ implementations. This is a basic principle behind the Web, and
making even a single exception leads to a dangerous slippery slope.

 _It seems they're trying to run it into the ground because they don't control
it_

No.

 _because it didn't go through their proper procedure, whereby it must have a
competitor._

Yes. In the long term, not having another implementation is a dangerous sign
-- it is a sign that developers are incapable of coming up with another
implementation. What if SQLite can't be ported to some hypothetical
architecture/stack in the future -- for example, a fully managed OS? What is
the guarantee that someone will be able to come up with another implementation
of the same spec which can run on that OS? At least with multiple
implementations you know that the problem is tractable.

 _Why? In what way is this helpful?_

It is helpful because it demonstrates long-term thinking.

 _And if they're not being helpful, what's their purpose? To be dogmatic and
prevent good ideas they didn't come up with from spreading?_

No, to think in the longer term than you do.

~~~
Groxx
And the multiple implementations of IndexedDB are...? (don't actually know. If
you do, I'd be interested in links)

Similarly, there are plenty of implementations of SQL out there. They don't
count?

~~~
sid0
_And the multiple implementations of IndexedDB are...? (don't actually know.
If you do, I'd be interested in links)_

There's an early one in Firefox 4 beta right now [1], and an upcoming one in
Chrome [2]. Microsoft will probably implement IndexedDB in a future version of
IE [3]. (IndexedDB isn't a standard right now either, but it'll be on track to
be one once two implementations are complete.)

[1] <https://wiki.mozilla.org/Firefox/Projects/IndexedDB>

[2] [http://www.chromium.org/developers/design-
documents/indexedd...](http://www.chromium.org/developers/design-
documents/indexeddb)

[3] [http://blogs.msdn.com/b/ie/archive/2010/03/09/working-
with-t...](http://blogs.msdn.com/b/ie/archive/2010/03/09/working-with-the-
html5-community.aspx)

 _Similarly, there are plenty of implementations of SQL out there. They don't
count?_

No, since none of them share all the peculiarities of SQLite. For example,
SQLite doesn't have type checking, while most other SQL databases do.

~~~
Groxx
I don't think _any_ browser shares all the peculiarities of any other browser.
That's hardly an argument against there being a W3C spec for HTML, CSS, the
DOM, or JavaScript. Why pick on SQL?

~~~
sid0
By "peculiarities" I didn't mean minor implementation differences but the
major ideas behind the implementation. Be reasonable here -- the differences
in implementation in the DOM between Gecko and WebKit (say) are trivial
compared to "type checking" vs "lack of type checking". There's a bit of
subjectivity involved, agreed, but I think any reasonable person would agree
about the differences.

~~~
Groxx
There are indeed differences. Much greater with SQLite vs (most) other SQL
engines.

I still see it as killing something out of some ulterior motive rather than
supporting something highly effective. SQLite exists because it has survived
against _many_ competitors for a _long_ time. It's not like this is some new,
untested thing that cropped up out of nowhere.

edit: just realized there's a _much_ stronger argument here. And a bigger
threat.

By not supporting WebDatabase, because the implementers all used SQLite,
they've essentially _guaranteed_ that they will never support an SQL-based
database. Few are going to want to compete with SQLite on its own turf as an
embedded database when it's already so optimized. _Especially_ if they all
have to agree on a spec similar to SQLite.

SQLite isn't even all that poor of a match for a JS-interfaced database. JS is
nearly as fast and loose with its types as SQLite, and the types that _do_
exist are very close to what JS has.

~~~
sid0
You still haven't answered what you're going to do if the current SQLite code
simply can't run on a particular OS stack. There's no guarantee that every
future stack will have a C compiler, or even allow C programs.

~~~
Groxx
All that matters is the behavior, which SQLite has very well defined because
it's a bit wonky out of maintaining backwards compatibility. Even the
fundamental algorithms will still translate, so all that's needed is to
compile it or something logically similar for the system with whatever
compiler it allows. Heck, it'd probably be _easier_ than implementing off an
abstract spec, especially when you consider most of the optimizations will
still translate but do not need to be discovered.

If such a system exists, it won't be able to run the vast majority of stuff
out there. Re-implementing SQLite will be the least of its concerns.

------
Groxx
Not quite, methinks:

> _This document was on the W3C Recommendation track but specification work
> has stopped. The specification reached an impasse: all interested
> implementors have used the same SQL backend (Sqlite), but we need multiple
> independent implementations to proceed along a standardisation path._

That notice has been up for quite a while now. They're just making it plainer
that they've given up, because there's already a spec out there that they
don't have control of.

Also, to perform a join in IndexedDB, you've gotta do it by hand, iterating
over the results and merging data programmatically[1]. While WebDatabases have
a PITA async-only API for reasons which are entirely beyond my comprehension,
SQL is an _incredibly_ capable language for interacting with a database, and
has _very_ mature and efficient implementations. Losing that would count as a
_massive_ loss to me. Why can't we have both? WebKit / Chrome is already going
this route, as they have WebDatabase and recently implemented IndexedDB as
well.

[1]: [http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-
web...](http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/)
example 4

~~~
nl
_While WebDatabases have a PITA async-only API for reasons which are entirely
beyond my comprehension_

That's because they want to support responsive applications. Javascript
doesn't really have native concurrency operations, so the best (only?) way to
do it is via async operations.

It's like XMLHttpRequest: Async only, which can be harder to program, but
makes it a lot more robust.

~~~
nex3
> Javascript doesn't really have native concurrency operations

Except for Web Workers, also part of HTML5. The way Google Gears handled this
was to allow synchronous database operations only in worker contexts.

~~~
pornel
Worker<->UI communication is asynchronous, and has additional limitations
(only copying, only JSON-able data), so synchronous worker API in many cases
would just shift complexity elsewhere.

~~~
Groxx
In part. It makes conditional, nested queries much simpler, however, when you
don't need to nest async callbacks 20 layers deep.

I understand that having a synchronous API would mean more people would use
it. But honestly, I see that as their problem. A fair number of queries, such
as "select * from your_table where id = ?", are _useful_ to have synchronous
as an option, and should perform quickly enough to be invisible. And
synchronous can easily be made asynchronous, but the other way around is
essentially impossible without any Thread.join.

------
Hixie
The W3C didn't kill it, it was Mozilla and Microsoft who decided they didn't
want to implement it (for a variety of reasonable reasons) and me who decided
to not continue working on a spec that didn't have all the browser vendors on
board.

------
amattie
No one has mentioned yet that both Android and iPhone implemented SQLite as
described in the draft spec. There's a tremendous number of developers --
including myself -- who have built apps against it. The described spec may not
become commonplace in desktop browsers, but it's an entirely different story
on advanced mobile devices where Mozilla / Microsoft have nearly zero
influence.

I definitely don't see this just suddenly evaporating or going unmaintained in
those platforms.

------
jchrisa
This spec isn't the only game for offline storage. IndexedDB is the favored
replacement: <http://www.w3.org/TR/IndexedDB/>

I like it because the API is much more web-like than SQL. Others have other
reasons to prefer it.

~~~
jamesaguilar
For someone unfamiliar with the term, what does "web-like" mean?

~~~
Groxx
I'll be obtuse, and claim it means "JavaScript-like". You know, multiple
"truthy" values, the inability to detect the difference between arrays and
objects, a weird mashup of OO and functional abilities, `=== undefined` but
`isNaN()`, and no real difference between integers and floats, and all the
math weirdness that goes with them. Browsers implementing the same thing
different ways, interacting with a system (the DOM) that's the same but
different everywhere, and patched together by multiple, usually-mutually-
exclusive libraries that everyone uses instead of the actual language.

(disclaimer: I've come to quite like JS, it's made some of my experiments
phenomenally simple. but it's weird.)

~~~
fforw
isNaN() only exists because the real way to detect NaN is so counter
intuitive. Lots of people will see "if (x !== x)" and will try to "optimize".

------
DjDarkman
Just great, it just seemed like we will have something this decade, but sadly
that will not be the case.

I have read the comments in Mozilla's thread
[http://hacks.mozilla.org/2010/06/beyond-html5-database-
apis-...](http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-
road-to-indexeddb/) they clearly don't give a damn about what the users want.

They should have just agreed on a simple subset of SQL instead of going NoSQL,
but apparently that wasn't good enough for them, waiting a decade more for
something to store data in is probably better.

I personally love the concept of NoSQL, it's just that IndexedDB needs a few
more years, which means it will probably even miss IE10.

------
jfb
Why, again, was this needed? HTML5 is _already_ looking like a security and
management shitstorm; anything that makes it simpler is fine by me.

~~~
Groxx
How is a domain-locked local SQL database a security shitstorm?

~~~
jfb
I suppose I'm just jumpy because of the lack of granularity in user control
over local storage, and wary of the eptitude of the browser vendors, and in
favor of fewer, smaller features. After reading the inept IndexedDB thing,
however, it seems like the _wrong_ local storage mechanism is going to get it
in the neck.

~~~
Groxx
You've got just as much control. Grab the console and 'drop table' - all that
data, gone. You can even trash all the databases in most browsers pretty
simply. And restrict their size. The difference is that client-side JavaScript
becomes _useful_ with a large-ish local storage.

Arguably, it's significantly safer than cookies, which are sent with every
request (ie: Firesheep).

~~~
ihsw
The issue would largely be storing sensitive data (I presume), namely
personally identifiable information. Imagine all the user data being stored in
a simple and quick API that advertisers (et al) can grab at, rather than
having to scrape through HTML bits on a page. Now imagine malware spreading
across the internet and frictionlessly gathering this data.

Although some might argue we're already there and that there's nothing
stopping the deluge of user information.

------
henryprecheur
I think that's a great news. HTML5 adds lots of complexity in the browser, and
yet don't address most of the fundamental problems of HTML: security,
complexity. Web SQL was another step in the wrong direction.

Local storage wont go away. I hope Web SQL will be replaced by something
"better" and more straightforward, A simple key-value database would be great.

~~~
patrickaljord
> A simple key-value database would be great.

That's exactly it:

<http://www.w3.org/TR/IndexedDB/>

~~~
duskwuff
IndexedDB is anything but simple.

------
ronaldj
Am I the only one that's sad about this?

~~~
k7d
Yeah, me too. I think it's just politics, in the best traditions of big
corporations, that doesn't do any good to actual web developers.

From practical perspective we would be better off with Web SQL DB.
Functionally it addresses everything a developer needs to create offline HTML
apps. API is not perfect but you can always improve that with small wrapper
libraries (like JQuery improves DOM API). You can always easily implement
IndexDB-like API on top off SQL if you really want that. The opposite is
probably possible but much more difficult.

Also I think IndexDB might turn out to be yet another compatibility headache
because everybody will be creating their own implementation (I'm pretty sure
there will be at least 3 - Microsoft, Mozilla & Webkit). It's a speculation
but most likely this wouldn't be an issue with Web SQL DB because everybody
would just use the same SQLLite backend.

And worst of all, this is delaying progress of web applications. Lack of solid
cross-browser client-side storage solution is the last big gap for next
generation of web applications. If everybody had just agreed on SQLLite we
could be there today... now it's still unknown when we will get there.

~~~
sid0
_Also I think IndexDB might turn out to be yet another compatibility headache
because everybody will be creating their own implementation (I'm pretty sure
there will be at least 3 - Microsoft, Mozilla & Webkit). It's a speculation
but most likely this wouldn't be an issue with Web SQL DB because everybody
would just use the same SQLLite backend._

For a proposed web standard to become an actual web standard there need to be
at least _two_ implementations. This is a _good_ , healthy thing. There was
going to be no second implementation of Web SQL, so it was never going to
become a standard.

------
Eil
So is IndexedDB a beefier version of localStorage or does it serve a different
purpose altogether?

~~~
jchrisa
Local storage is just key/value queries, IndexedDB allows you to make range
queries against indexes you define, so you can get eg: recent blog posts, etc.

~~~
mindeh
yeah. to give an example:

if I want to store persist objects using localStorage, I'd convert them to
JSON and store key-value. However I cannot store whole object hierarchy as
it'll soon become an overkill.

so I store separate objects, and recreate relations upon retrieval manually.
But I also need to maintain my own index - to know which objects I have stored
under what keys.

------
mindeh
The heading is misleading imho.

As you see written in the spec, it was on the track to W3 Recommendation, but
as every vendor who implemented it chose SQLite, there was little to do about
it.

In other words, it isn't a "kill", just end of active maintainence. But spec
as it is, is pretty solid. And WebSQL is here to stay in WebKit - there are
just too many apps dependent on it to kill it. And no good reason to kill as
there's no viable alternative on the horizon.

Summing up - WebKit (so iOS, Android and others) has it and will have it for
quite a while, IE won't, FF won't too.

------
briandon
SQLite is already baked into Firefox and available to Firefox itself and to
extensions/addons, although not available to web page authors:

<https://developer.mozilla.org/en/Storage>

------
ficeto
So reading all the comments I see that most "against" are because "Because if
everyone used SQLite there would be no second implementation, which is
something that is necessary for a proposed standard to become an actual
standard." WTF? Do we need to implement MySQL, PGSQL or MSSQL to get a chance
of having SQL in our browsers? Does that sound stupid only to me? Is Mozilla
trying to follow the "success" of IE? Who pays W3C? Why do they play like the
God of Web? And why can't we have both? I certainly don't want to ever use
IndexedDB if I have and SQL option.

------
jasongullickson
So what does this mean for browsers that support web SQL and apps that are
built on it? Is it likely that Safari, Chrome, etc. will drop support for it
before a viable alternative is avaliable?

~~~
pornel
It will be maintained until IndexedDB becomes viable.

Perhaps someone will write JS library that implements IndexedDB on top of
WebSQL (or vice-versa).

------
uriel
Lets hope it stays dead, seems that we just dodged a pretty nasty bullet.
IndexDB seems to also be ridiculously complex, but as wicked as most standards
are anything is better than SQL.

------
alkavan
why would you write SQL with JavaScript? don't think that JavaScript yet at a
point it can run heavy GUI element, handle AJAX, maybe Video or 3D _and_ Query
a database. JavaScript likes JSON very much, so all you need is just export
your data with a language like PHP in JSON format, and handle it with
JavaScript.

------
bluedevil2k
There's enough security/privacy issues with cookies, and those are simple text
strings. Imagine the issues a nefarious mind could cause with a DB.

~~~
drivebyacct2
Just imagine how scary it wouldn't be if you understood the security
implications and risks of cookies compared to the lack there of for a local
browser db storage....

------
jhrobert
If the SQL guys were serious about their shit they should have patch some
JavaScript at the syntax level.

Instead they pushed/lobbied for the usual broken binding that is the very
reason SQL is so contreversed: impedance mismatch.

Of course, hacking a javascript parser to introduce some SQL semantic in it is
not exactly "easy"

Basically, the initiative was doomed from day one, what a waste of time...

~~~
rsanders
I'm not sure what you're trying to say. SQL works quite well in just about
every language there is without introducing new syntax. Are you talking about
something like LINQ? Nice, but unnecessary.

