
Removing WebSQL Support - bzbarsky
https://lists.webkit.org/pipermail/webkit-dev/2019-November/030968.html
======
kragen
Kind of a shame, since SQLite is about a thousand times easier to program for
than IndexedDB, but inevitable.

~~~
sebazzz
IndexedDB is all new and "NoSQL".

~~~
kragen
Well, and the interface is async (though in a shitty way that requires a lot
of effort to wrap in sane promises) and the behavior spec is simple enough
that you could plausibly have multiple implementations, which is the stumbling
block that killed WebSQL.

~~~
wayneftw
That's a stumbling block according to Mozilla's flawed logic [1]. First they
said "nobody wants SQL" \- which couldn't have been further from the truth -
but it was probably due to the fact that they wholly drank the kool-aid during
the height of the NoSQL fad... and somehow, to them, it was better to have
multiple implementations of some piece of shit that nobody wanted to use
(right from the very beginning) instead of one perfect, well respected and
well tested implementation of something that people obviously really did want
to use.

It's absolute bullshit and it's the type of bad decision that they have a
history of making which causes me to not be a fan of Mozilla.

[1] [https://nolanlawson.com/2014/04/26/web-sql-database-in-
memor...](https://nolanlawson.com/2014/04/26/web-sql-database-in-memoriam/)

~~~
derefr
> instead of one perfect, well respected and well tested implementation of
> something that people obviously really did want to use.

...until SQLite changes any of its internal APIs in some breaking way.
SQLite's API (the C one, not the SQL one) is only defined relative to itself,
rather than to any standard. It doesn't have to be stable; it can do what it
wants. So, when SQLite changes that API, what are browsers supposed to do?
Just blindly follow the changes, breaking the web each time? Keep things the
way they are, drifting slowly out of sync until eventually they're maintaining
a fork? Or perhaps a little bit of both, each vendor choosing differently,
making the web once again a broken mess of polyfills?

This is why standards exist. Mozilla would be just fine with SQLite _as an
implementation_ if there was some stable "embedded SQL client" API standard
they could use and point the other vendors to that would say exactly what JS
developers should be seeing and talking to, which would evolve at its own pace
regardless of any implementation-level changes of SQLite, with adapter
libraries that would paper over those changes until the standard catches up.

As it is, Mozilla would have to invent and maintain that standard themselves,
and they're not interested in doing so.

~~~
infinite8s
Or you know, they could have just used SQL.

~~~
kragen
Implementing SQL, even a reasonable SQL subset, is a lot harder than
implementing IndexedDB.

~~~
wayneftw
Implementing car engines is a lot harder than building wagons. So we should
just go back to using wagons.

~~~
kragen
We definitely should not have standardized a worldwide standard design for car
engines 40 years into the history of the automobile that everybody is required
to implement bug-compatibly and nobody is allowed to change.

------
coleifer
It's too bad and honestly kinda a bummer how all this panned out.

Mozilla people pushed really hard against "just use sqlite" because it's not a
spec, and compatible alternatives would need to implement some of the quirks
of sqlite. Unfortunately, nothing as good as sqlite has ever materialized, but
this argument essentially blocked websql from becoming "officially blessed" by
the w3c.

Around this time Mozilla was also was drinking the koolaid hard and somehow we
ended up with something literally nobody wanted: indexeddb. There's a funny
article which is made even better by it's earnest, unironic use of the term
"aesthetics" to describe indexeddb [1].

Another tragic instance of design-by-committee and a complete lack of
pragmatism.

[1] [https://hacks.mozilla.org/2010/06/beyond-html5-database-
apis...](https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-
road-to-indexeddb/)

~~~
nine_k
No two independent implementations -> not standard-worthy :(

I would love to see an SQL interface in the browser. I suppose it's going to
be a library on top of indexed DB, and / or a WASM implementation. Then it
would have a chance to become a standard.

------
no_wizard
For those looking for a pretty decent (and small) wrapper around IndexDB, I've
had some good luck using localforage

[https://github.com/localForage/localForage](https://github.com/localForage/localForage)

I believe its maintained by Mozilla still.

There's also idb-keyval

[https://github.com/jakearchibald/idb-
keyval](https://github.com/jakearchibald/idb-keyval)

~~~
shortercode
There's currently a proposal called "KVStorage" to add a localforage style
inbuilt module to browsers.

[https://developers.google.com/web/updates/2019/03/kv-
storage](https://developers.google.com/web/updates/2019/03/kv-storage)

I'm not totally agreed with the idea of inbuilt modules, but the API is very
pleasant.

I work on a fairly large project that relied on localforage for a long time.
However, we have since moved to our own library to resolve a number of small
issues we had with localforage.

------
dang
Long time coming. 2014:
[https://news.ycombinator.com/item?id=7661236](https://news.ycombinator.com/item?id=7661236)

2010:
[https://news.ycombinator.com/item?id=1920220](https://news.ycombinator.com/item?id=1920220)

------
shortercode
Sad to hear WebSQL is finally going away. I used it a number of years ago for
a mobile only project. At the time indexeddb was effectively unusable on iOS,
and the data we had was too large and complex to store in localstorage. WebSQL
was perfect for the role, and worked really well.

The only issues I had with it are the lack of documentation and the fact IE,
Edge and Firefox didn't support it. Perhaps it's not surprising that the MDN
documentation was lacking, but I made do. Browser support on mobile was
actually really good, so that didn't cause any issues.

Nowadays I'm relatively familiar with indexeddb, but I'm convinced the same
project would be harder to implement with it.

------
kfir
The web spec has been in maintenance mode for some time -
[https://www.w3.org/TR/webdatabase/](https://www.w3.org/TR/webdatabase/)

------
lightgreen
I’m the only one who is happy about this change?

Browsers should only provide low level well defined unambiguous APIs with good
forward compatibility. WebSQL is not that kind of API.

And higher level APIs like SQL can be done by user libraries.

Same way operating system comes with file system API, but users choose
whatever database they prefer, and database is implemented using file system
API.

------
fwxwi
This guy has sent this as HTML mail, but also I see the "gmail_signature"
class in it. Does it mean he's actually using his webkit.org mail from a Gmail
account?

~~~
kijin
webkit.org MX records point to Apple, but Gmail can send and receive emails on
behalf of any account that supports POP/IMAP/SMTP.

