Hacker News new | past | comments | ask | show | jobs | submit login
Removing WebSQL Support (webkit.org)
68 points by bzbarsky on Nov 22, 2019 | hide | past | favorite | 26 comments



Kind of a shame, since SQLite is about a thousand times easier to program for than IndexedDB, but inevitable.


I've used sql.js (https://github.com/kripken/sql.js) which is SQLite compiled to WASM. It works pretty well, for some use cases.


IndexedDB is all new and "NoSQL".


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.


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


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


Or you know, they could have just used SQL.


Yes, the same as all the other databases that just “use SQL”. We all know how compatible they are.


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


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


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.


I said above:

> SQLite's API (the C one, not the SQL one)

To be clear of what I meant by this, it's not that SQLite has an API that you can use "instead of" SQL (like e.g. Z3 has a C API you can use "instead of" communicating via the LIB-SMT format) but rather that there are plenty of things you need to do to/in/with a DBMS that aren't covered by SQL itself, because SQL is designed around the needs of a client-server connection to a running steady-state database instance.

In any case with a client-server RDBMS, where you'd need to manage it by connecting directly to the DBMS instance host and editing config files or using DBMS-package-supplied CLI commands, SQLite instead exposes these configuration and management operations through C API calls.

Also, any "lower-level" operations that are part of the (proprietary) transport protocol for a client-server RDBMS, like statement parameter binding, delivery of notifications, or early termination of result streaming, are also done through the C API in SQLite, just like they're done through a protocol adapter library's API in a client-server RDBMS.

For your application to create, manage, and use a SQLite database, it needs to use both of these kinds of APIs. Thus, for a web browser to usefully expose SQLite to Javascript, it would need to expose these APIs on the SQLite Database object (which is precisely what WebSQL does.)

But neither the SQLite's "DB management" APIs, nor its "low-level protocol" APIs, have any standard keeping them stable in the way that SQL itself is stable. The API that SQLite exposes for this is precisely just "the API that SQLite exposes for this." It's made up, and nothing else implements it, because SQLite is the only embedded SQL RDBMS, so it's the only thing that needs an API like this, and so there's never been a need to unify SQLite's API with any other such API, and so there's never been a standards body created to accomplish such a task.

Which is a problem, if you'd like you guarantee that an API function equivalent to e.g. "sqlite3_bind_blob64" is going to still be there tomorrow. WebSQL makes no such guarantee. If SQLite changes tomorrow and gets rid of that function, then WebSQL-the-"standard" would also change tomorrow and get rid of that function. (Or, a more likely example: if tomorrow SQLite found a security flaw in the semantics of sqlite3_prepare_v2(), and responded by implementing a sqlite3_prepare_v3() with different semantics and deprecating sqlite3_prepare_v2(); then WebSQL-the-"standard" would likely respond by making its single "prepare" API now suddenly obey the prepare_v3 semantics.)

Thus, WebSQL is no standard at all.


Thank you, that's a very cogent reply to my rather flippant remark. Now I understand the reasoning behind not standardizing on WebSQL.


> That's a stumbling block according to Mozilla's flawed logic

No, it doesn't have anything to do with Mozilla or NoSQL. The basis of internet standards is and has always been to have multiple compatible independent implementations. Things that don't manage to rise to that bar don't and shouldn't become internet standards, because the point of standardizing the spec is to permit compatible independent reimplementations.

Nothing is stopping WebKit from continuing to offer SQLite to JavaScript (whether in the form of WebSQL or in some improved form that supports async I/O). Except that they apparently don't want to, because they don't want to be responsible for it.


They have a mental disease of reinventing the wheel.


You forgot "is web scale" ;)

Oh my, that meme was in 2010, almost a decade ago...


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

I believe its maintained by Mozilla still.

There's also idb-keyval

https://github.com/jakearchibald/idb-keyval


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

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.



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.


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.


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


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


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.


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?


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: