5 ms·

Removing WebSQL Support

68 points by bzbarsky 7y ago

dang 7y ago
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
kfir 7y ago
The web spec has been in maintenance mode for some time - https://www.w3.org/TR/webdatabase/ https://www.w3.org/TR/webdatabase/
kragen 7y ago
Kind of a shame, since SQLite is about a thousand times easier to program for than IndexedDB, but inevitable.
- sebazzz 7y ago
  IndexedDB is all new and "NoSQL".
  - kragen 7y ago
    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 7y ago
      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-memoriam/ https://nolanlawson.com/2014/04/26/web-sql-database-in-memor...
      - derefr 7y ago
        > 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 7y ago
        Or you know, they could have just used SQL.
        kragen 7y ago
        Implementing SQL, even a reasonable SQL subset, is a lot harder than implementing IndexedDB.
        wayneftw 7y ago
        Implementing car engines is a lot harder than building wagons. So we should just go back to using wagons.
        kragen 7y ago
        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.
  - drdaeman 7y ago
    You forgot "is web scale" ;) Oh my, that meme was in 2010, almost a decade ago...
- edko 7y ago
  I've used sql.js (https://github.com/kripken/sql.js https://github.com/kripken/sql.js) which is SQLite compiled to WASM. It works pretty well, for some use cases.
deleted 7y ago
[deleted]
no_wizard 7y 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 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 7y ago
  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.
fwxwi 7y ago
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 7y ago
  webkit.org MX records point to Apple, but Gmail can send and receive emails on behalf of any account that supports POP/IMAP/SMTP.
coleifer 7y ago
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-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...
- nine_k 7y ago
  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.
shortercode 7y ago
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.
lightgreen 7y ago
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.

68 points by bzbarsky 7y ago

dang 7y ago

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

kfir 7y ago

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

kragen 7y ago

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

sebazzz 7y ago
IndexedDB is all new and "NoSQL".
- kragen 7y ago
  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 7y ago
    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-memoriam/ https://nolanlawson.com/2014/04/26/web-sql-database-in-memor...
    - derefr 7y ago
      > 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 7y ago
        Or you know, they could have just used SQL.
        kragen 7y ago
        Implementing SQL, even a reasonable SQL subset, is a lot harder than implementing IndexedDB.
        wayneftw 7y ago
        Implementing car engines is a lot harder than building wagons. So we should just go back to using wagons.
        kragen 7y ago
        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.
- drdaeman 7y ago
  You forgot "is web scale" ;) Oh my, that meme was in 2010, almost a decade ago...
edko 7y ago
I've used sql.js (https://github.com/kripken/sql.js https://github.com/kripken/sql.js) which is SQLite compiled to WASM. It works pretty well, for some use cases.

deleted 7y ago

[deleted]

no_wizard 7y 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 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 7y ago
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.

fwxwi 7y ago

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 7y ago
webkit.org MX records point to Apple, but Gmail can send and receive emails on behalf of any account that supports POP/IMAP/SMTP.

coleifer 7y ago

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-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

nine_k 7y ago
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.

shortercode 7y ago

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.

lightgreen 7y ago

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.