3 ms·

They aren’t working to standardise SQLite, the are working to standardise a low level block based file system api that SQLite and other database engine can use.

They aren’t working to standardise SQLite, the are working to standardise a low level block based file system api that SQLite and other database engine can use. Thats much more exciting than “standardising SQLite” for the web. The Origin Privet File System api is going to provide the opportunity for any db engine to be used in offline first PWAs. There is no “one size fits all” database engine, that was proved by both WebSQL and IndexedDB. The OPFS in combination with WASM is the correct solution to in browser DBs.

justin66 4y ago
> There is no “one size fits all” database engine, that was proved by both WebSQL and IndexedDB. Thanks to a few very small people, WebSQL was deprecated before it had a chance to prove anything.
- chrismorgan 4y ago
  WebSQL was killed off because the direction it was heading was certain to cause major compatibility problems down the road, and no one was willing to do the work that would be required to avert that (and no one was sold that it would be worth it even at that).
- kevingadd 4y ago
  Most likely prove its utility as an attack surface and source of compatibility issues
- nine_k 4y ago
  They had a,point. Making something a standard when only one implementation of it exists is not prudent. There was (and still is) no independent implementation of SQLite that was battle-tested even a bit.
ilyt 4y ago
> There is no “one size fits all” database engine, that was proved by both WebSQL and IndexedDB. It was not proven at all. WebSQL was deprecated based on "we don't want to standarize on single project". IndexedDB happened because they wanted to standarize on single API (lmao), but it was just too inept. There is no one size fits all but WebSQL fit A LOT of use cases. Low level storage that works for DBs is interesting idea but that also means you need to ship additional megabytes of code with every app.
- endorphine 4y ago
  Why megabytes though? Couldn't this be in the range of 100-300kb? Also, couldn't the implementation of that storage spec. be shipped in the standard JS web APIs (i.e. by the browser)? Why would it be in every app?
  - exelib 4y ago
    Although I agree that modern web apps suffers from the size already and additional 300kb doesn't hurt in this case, but one of the most popular use cases for the client DB is the offline capability for an small footprint web app. You know, it is when your connection is poor or even absent. 300kb hurt really badly. > Also, couldn't the implementation of that storage spec. be shipped in the standard JS web APIs (i.e. by the browser)? Why would it be in every app? Actually, that is exactly what happens to WebSQL and IndexedDB. WebSQL got deprecated, they were not able integrate SQLite, and created IndexedDB, which is hated by many developers. Just an example: https://news.ycombinator.com/item?id=27511941 https://news.ycombinator.com/item?id=27511941

justin66 4y ago

> There is no “one size fits all” database engine, that was proved by both WebSQL and IndexedDB. Thanks to a few very small people, WebSQL was deprecated before it had a chance to prove anything.

chrismorgan 4y ago
WebSQL was killed off because the direction it was heading was certain to cause major compatibility problems down the road, and no one was willing to do the work that would be required to avert that (and no one was sold that it would be worth it even at that).
kevingadd 4y ago
Most likely prove its utility as an attack surface and source of compatibility issues
nine_k 4y ago
They had a,point. Making something a standard when only one implementation of it exists is not prudent. There was (and still is) no independent implementation of SQLite that was battle-tested even a bit.

ilyt 4y ago

> There is no “one size fits all” database engine, that was proved by both WebSQL and IndexedDB. It was not proven at all. WebSQL was deprecated based on "we don't want to standarize on single project". IndexedDB happened because they wanted to standarize on single API (lmao), but it was just too inept. There is no one size fits all but WebSQL fit A LOT of use cases. Low level storage that works for DBs is interesting idea but that also means you need to ship additional megabytes of code with every app.

endorphine 4y ago
Why megabytes though? Couldn't this be in the range of 100-300kb? Also, couldn't the implementation of that storage spec. be shipped in the standard JS web APIs (i.e. by the browser)? Why would it be in every app?
- exelib 4y ago
  Although I agree that modern web apps suffers from the size already and additional 300kb doesn't hurt in this case, but one of the most popular use cases for the client DB is the offline capability for an small footprint web app. You know, it is when your connection is poor or even absent. 300kb hurt really badly. > Also, couldn't the implementation of that storage spec. be shipped in the standard JS web APIs (i.e. by the browser)? Why would it be in every app? Actually, that is exactly what happens to WebSQL and IndexedDB. WebSQL got deprecated, they were not able integrate SQLite, and created IndexedDB, which is hated by many developers. Just an example: https://news.ycombinator.com/item?id=27511941 https://news.ycombinator.com/item?id=27511941