24 ms·

Reminder that Mozilla killed off SQLite in the browser, to push indexedDB, a much more limited database that they then went and implemented in Firefox with... S

Reminder that Mozilla killed off SQLite in the browser, to push indexedDB, a much more limited database that they then went and implemented in Firefox with... SQLite.

jrockway 4y ago
This is SQLite compiled to WebAssembly along with a storage layer ("virtual filesystem") that fetches database pages from a web server. So you have the full power of SQLite, and the page doesn't have to download unnecessary data from the server (like the entire dataset just to show you one row). It's a super nifty hack. SQLite built into the browser is somewhat orthogonal to this concern; it didn't allow you to store database pages on the server, and this one doesn't let you write to it.
pfundstein 4y ago
That's a bit misleading. IndexedDB is a standard maintained by the World Wide Web Consortium (W3C) and is supported by all major browsers. Web SQL Database was a prior API developed by Apple. But Firefox refused to add support for it and argued against it becoming a standard because it would codify the quirks of SQLite. It was thus deprecated in favor of IndexedDB.
kevingadd 4y ago
I hate indexedDB as much as almost anyone, but this is not an accurate characterization of what happened. People wanted to ship 'just SQLite' and magically anoint an open source library as a standard. There are lots of problems with that.
- rrdharan 4y ago
  Still fair to ask, given the world we have now where there’s kinda just “nothing” / broken and crappy implementations, would the alternative world in which SQLite was anointed, have been better head-to-head? I think maybe yes it would have? The perfect defeated the good?
  - podviaznikov 4y ago
    maybe it could have been better. But aren’t we talking from the decisions that happened more than 10 years ago? websql was created in 2010 and IndexedD work started also in 2010 - or around those years. Sqlite didn’t have this amazing reputation it has now back then and decision to have Indexed DB as a standard looked good. At least that is what I remember just reading about it from 2010-2013. In retrospect it’s easier to say that probably the alternative would be better. But I don’t think it was the same decade ago.
doliveira 4y ago
Which was the right choice, web standards shouldn't be tied to a single project.
- LAC-Tech 4y ago
  Making a standard for WebSQL would have been the path of least resistance.
  - matharmin 4y ago
    SQLite is a massive library, with a lot of functionality and optional extensions, and behaviour is added or changed over versions. Codifying all the behaviour into a standard would be a massive effort. And then you're either stuck on that version of SQLite, or your standard depends on what an external project is doing with new releases - which is really not what you want for a web standard. Alternatively, you need to pick a small stable subset of SQLite functionality to expose. But that would mean you can't just use plain SQLite anymore - you either need to modify it significantly, or need to wrap it somehow. Which either way adds a lot of overhead again.
- simula67 4y ago
  Usually standards will have holes. Therefore, it is necessary to ask: what happens when a competing standard notices a hole in the current standard? In this case, it is better to have a reference implementation, matching which, the competing implementation should have programs that depend on the standard to continue to work. Therefore, tying a standard to a reference implementation, especially one as reputed as SQLite, might not have been a bad outcome overall.
- brigandish 4y ago
  It's an open source project, they could've forked it and got their wish to keep the API unaffected by any changes to SQLite. This blog post[1], this amazing blog post gives us all the insight needed to know this was going to go badly. The bit about whiteboarding a replacement, is that better or worse than believing Javascript is really a replacement for SQL? Or that IndexedDB is somehow elegant? I can't tell, the whole thing makes me cringe. [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...
deleted 4y ago
[deleted]
matharmin 4y ago
The new origin-private filesystem allows random access reads and writes. This should give the possibility to use WASM SQLite in the browser with local persistence - everything that WebSQL had. A major advantage over WebSQL is that the developer is in complete control. The developer can pick the latest version of SQLite, enable any custom extensions (standard or additional ones), or use SQLCipher for encryption, instead of just using whatever the browser provides. The only real disadvantage is the download size of the wasm code, but it's small enough that it won't be a blocker for sizeable interactive web apps. Just don't do this for your static blog.

Reminder that Mozilla killed off SQLite in the browser, to push indexedDB, a much more limited database that they then went and implemented in Firefox with... SQLite.

jrockway 4y ago

This is SQLite compiled to WebAssembly along with a storage layer ("virtual filesystem") that fetches database pages from a web server. So you have the full power of SQLite, and the page doesn't have to download unnecessary data from the server (like the entire dataset just to show you one row). It's a super nifty hack. SQLite built into the browser is somewhat orthogonal to this concern; it didn't allow you to store database pages on the server, and this one doesn't let you write to it.

pfundstein 4y ago

That's a bit misleading. IndexedDB is a standard maintained by the World Wide Web Consortium (W3C) and is supported by all major browsers. Web SQL Database was a prior API developed by Apple. But Firefox refused to add support for it and argued against it becoming a standard because it would codify the quirks of SQLite. It was thus deprecated in favor of IndexedDB.

kevingadd 4y ago

I hate indexedDB as much as almost anyone, but this is not an accurate characterization of what happened. People wanted to ship 'just SQLite' and magically anoint an open source library as a standard. There are lots of problems with that.

rrdharan 4y ago
Still fair to ask, given the world we have now where there’s kinda just “nothing” / broken and crappy implementations, would the alternative world in which SQLite was anointed, have been better head-to-head? I think maybe yes it would have? The perfect defeated the good?
- podviaznikov 4y ago
  maybe it could have been better. But aren’t we talking from the decisions that happened more than 10 years ago? websql was created in 2010 and IndexedD work started also in 2010 - or around those years. Sqlite didn’t have this amazing reputation it has now back then and decision to have Indexed DB as a standard looked good. At least that is what I remember just reading about it from 2010-2013. In retrospect it’s easier to say that probably the alternative would be better. But I don’t think it was the same decade ago.

doliveira 4y ago

Which was the right choice, web standards shouldn't be tied to a single project.

LAC-Tech 4y ago
Making a standard for WebSQL would have been the path of least resistance.
- matharmin 4y ago
  SQLite is a massive library, with a lot of functionality and optional extensions, and behaviour is added or changed over versions. Codifying all the behaviour into a standard would be a massive effort. And then you're either stuck on that version of SQLite, or your standard depends on what an external project is doing with new releases - which is really not what you want for a web standard. Alternatively, you need to pick a small stable subset of SQLite functionality to expose. But that would mean you can't just use plain SQLite anymore - you either need to modify it significantly, or need to wrap it somehow. Which either way adds a lot of overhead again.
simula67 4y ago
Usually standards will have holes. Therefore, it is necessary to ask: what happens when a competing standard notices a hole in the current standard? In this case, it is better to have a reference implementation, matching which, the competing implementation should have programs that depend on the standard to continue to work. Therefore, tying a standard to a reference implementation, especially one as reputed as SQLite, might not have been a bad outcome overall.
brigandish 4y ago
It's an open source project, they could've forked it and got their wish to keep the API unaffected by any changes to SQLite. This blog post[1], this amazing blog post gives us all the insight needed to know this was going to go badly. The bit about whiteboarding a replacement, is that better or worse than believing Javascript is really a replacement for SQL? Or that IndexedDB is somehow elegant? I can't tell, the whole thing makes me cringe. [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...

deleted 4y ago

[deleted]

matharmin 4y ago

The new origin-private filesystem allows random access reads and writes. This should give the possibility to use WASM SQLite in the browser with local persistence - everything that WebSQL had. A major advantage over WebSQL is that the developer is in complete control. The developer can pick the latest version of SQLite, enable any custom extensions (standard or additional ones), or use SQLCipher for encryption, instead of just using whatever the browser provides. The only real disadvantage is the download size of the wasm code, but it's small enough that it won't be a blocker for sizeable interactive web apps. Just don't do this for your static blog.