6 ms·

The Web SQL standard was deprecated (by Mozilla) on the grounds of a single implementation. The result today: A single SQL implementation with no standard (bey

by yyyk 4y ago

The Web SQL standard was deprecated (by Mozilla) on the grounds of a single implementation. The result today: A single SQL implementation with no standard (beyond SQLite) and therefore no easy way for anyone to create a compatible alternate implementation.

roblabla 4y ago
Or an alternative read of the result today: A simple implementation of filesystem access, on top of which any number of database (SQL or not) can be implemented, thus allowing for more innovation in the database space.
ngrilly 4y ago
Nothing is preventing you to "create a compatible alternate implementation".
CJefferson 4y ago
However, now every webbrowser doesn't have to keep it correct, secure and up to date for the next 40 years.
- lxgr 4y ago
  Yes, now every single site using SQLite has to do that.
simonw 4y ago
Thanks to Mozilla rejecting Web SQL we now get to run the exact version of SQLite we need, compiled to WASM and downloaded to the browser rather than being baked in and unable to upgrade. SQLite not right for a project? DuckDB has a WASM build too. Heck, so does PostgreSQL now! https://www.crunchydata.com/blog/crazy-idea-to-postgres-in-the-web-browser https://www.crunchydata.com/blog/crazy-idea-to-postgres-in-t...
- yyyk 4y ago
  (Replying to this and other comments in unison) A SQL standard never precluded a separate filesystem access standard and implementing databases on top of it. But rejecting the Web SQL standard means that every SQL-using webapp will be tied to its own database - replicating the SQL incompatibility mess when we had a chance to finally enforce a little standardization based on current SQL standards - and require depending on WASM when WASM might have not been necessary.
  - acdha 4y ago
    > But rejecting the Web SQL standard means that every SQL-using webapp will be tied to its own database - replicating the SQL incompatibility mess when we had a chance to finally enforce a little standardization based on current SQL standards Web SQL was dropped for precisely this reason: > The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. http://www.w3.org/TR/webdatabase/ http://www.w3.org/TR/webdatabase/ Without a magic want to force multiple implementations, all of those web apps would have been tied to a single implementation anyway _and_ it would have been harder to update it so even after something was fixed you'd need to wait until the oldest browsers were updated before you could rely on it. That is possible, of course, but it's a recipe for problems with something like a SQL database.
    - xenadu02 4y ago
      SQLite is the one project that deserves an exception. There is a near zero chance anyone else can do better with similar quality (and test coverage!) Sometimes you need to be pragmatic IMHO.
      - samwillis 4y ago
        SQLite fits one generic model, and is a row level data store. DuckDB is a column store, and other DBs are designed to operate for specific use cases. This is open to all options. The point is that SQLite is a brilliant genetic option, but should not be the only option. WASM and OPFS is the right route forward to enable application developers to use the best data store architecture for their use case. Even within SQLite there are extension that would never have been an available to WebSQL that with this design are.
- abtinf 4y ago
  Isn’t the logical conclusion of this view the end of web browsers, replacing them with executable software distribution?
  - cudgy 4y ago
    Blasphemy! More fun to deal with compatibilities of running in different browsers. Seems like we have returned full circle (25 yrs later) to a new form of ActiveX plugins.
acdha 4y ago
That's the difference between a platform and an application using that platform. If SQLite is baked into your browser, you can only use the subset of functionality supported by the oldest / weirdest browser which your users use. Think about the DOM APIs: jQuery was super popular in the 2000s. Say all of the browsers had decided to bundle it like WebSQL bundled SQLite. Would you be happy using a copy of jQuery 1.7 until all of Apple, Microsoft, Mozilla, and Google shipped 1.8 and all of your users upgrade or would you prefer to update your site to reference the version with the features you want to use? (or switch to a different framework in 5 years) Browser developers always have to balance the tension of adding something new with the knowledge that they're going to need to support it for long periods of time. WASM is a good compromise position because it reduces performance as the reason why something should live in the browser engine rather than being shipped as an app resource.
- yyyk 4y ago
  >jQuery was super popular in the 2000s. Say all of the browsers had decided to bundle it like WebSQL bundled SQLite. This ignores the fact that SQL already has standards with multiple implementations and is very well established. It's not a recent-ish JS library. It's not new tech. It's an almost 50 year old tech predating the internet. Standardizing on a basic standard subset using the current SQL standards would have been enough for nearly all apps, and would have allowed alternate implementations without any real SQLite path dependency since SQL already has standards and well trotted paths for implementing them (at least a basic subset). [EDIT: I don't wish to spam the comments. If you wish to reply to this, please use the other thread you also replied to? I should have done it myself, sorry about that.]
- treis 4y ago
  >Would you be happy using a copy of jQuery 1.7 until all of Apple, Microsoft, Mozilla, and Google shipped 1.8 and all of your users upgrade I'd polyfill 1.8 until enough browsers support it like is done for every other browser api
deleted 4y ago
[deleted]

by yyyk 4y ago

roblabla 4y ago

Or an alternative read of the result today: A simple implementation of filesystem access, on top of which any number of database (SQL or not) can be implemented, thus allowing for more innovation in the database space.

ngrilly 4y ago

Nothing is preventing you to "create a compatible alternate implementation".

CJefferson 4y ago

However, now every webbrowser doesn't have to keep it correct, secure and up to date for the next 40 years.

lxgr 4y ago
Yes, now every single site using SQLite has to do that.

simonw 4y ago

Thanks to Mozilla rejecting Web SQL we now get to run the exact version of SQLite we need, compiled to WASM and downloaded to the browser rather than being baked in and unable to upgrade. SQLite not right for a project? DuckDB has a WASM build too. Heck, so does PostgreSQL now! https://www.crunchydata.com/blog/crazy-idea-to-postgres-in-the-web-browser https://www.crunchydata.com/blog/crazy-idea-to-postgres-in-t...

yyyk 4y ago
(Replying to this and other comments in unison) A SQL standard never precluded a separate filesystem access standard and implementing databases on top of it. But rejecting the Web SQL standard means that every SQL-using webapp will be tied to its own database - replicating the SQL incompatibility mess when we had a chance to finally enforce a little standardization based on current SQL standards - and require depending on WASM when WASM might have not been necessary.
- acdha 4y ago
  > But rejecting the Web SQL standard means that every SQL-using webapp will be tied to its own database - replicating the SQL incompatibility mess when we had a chance to finally enforce a little standardization based on current SQL standards Web SQL was dropped for precisely this reason: > The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. http://www.w3.org/TR/webdatabase/ http://www.w3.org/TR/webdatabase/ Without a magic want to force multiple implementations, all of those web apps would have been tied to a single implementation anyway _and_ it would have been harder to update it so even after something was fixed you'd need to wait until the oldest browsers were updated before you could rely on it. That is possible, of course, but it's a recipe for problems with something like a SQL database.
  - xenadu02 4y ago
    SQLite is the one project that deserves an exception. There is a near zero chance anyone else can do better with similar quality (and test coverage!) Sometimes you need to be pragmatic IMHO.
    - samwillis 4y ago
      SQLite fits one generic model, and is a row level data store. DuckDB is a column store, and other DBs are designed to operate for specific use cases. This is open to all options. The point is that SQLite is a brilliant genetic option, but should not be the only option. WASM and OPFS is the right route forward to enable application developers to use the best data store architecture for their use case. Even within SQLite there are extension that would never have been an available to WebSQL that with this design are.
abtinf 4y ago
Isn’t the logical conclusion of this view the end of web browsers, replacing them with executable software distribution?
- cudgy 4y ago
  Blasphemy! More fun to deal with compatibilities of running in different browsers. Seems like we have returned full circle (25 yrs later) to a new form of ActiveX plugins.

acdha 4y ago

That's the difference between a platform and an application using that platform. If SQLite is baked into your browser, you can only use the subset of functionality supported by the oldest / weirdest browser which your users use. Think about the DOM APIs: jQuery was super popular in the 2000s. Say all of the browsers had decided to bundle it like WebSQL bundled SQLite. Would you be happy using a copy of jQuery 1.7 until all of Apple, Microsoft, Mozilla, and Google shipped 1.8 and all of your users upgrade or would you prefer to update your site to reference the version with the features you want to use? (or switch to a different framework in 5 years) Browser developers always have to balance the tension of adding something new with the knowledge that they're going to need to support it for long periods of time. WASM is a good compromise position because it reduces performance as the reason why something should live in the browser engine rather than being shipped as an app resource.

yyyk 4y ago
>jQuery was super popular in the 2000s. Say all of the browsers had decided to bundle it like WebSQL bundled SQLite. This ignores the fact that SQL already has standards with multiple implementations and is very well established. It's not a recent-ish JS library. It's not new tech. It's an almost 50 year old tech predating the internet. Standardizing on a basic standard subset using the current SQL standards would have been enough for nearly all apps, and would have allowed alternate implementations without any real SQLite path dependency since SQL already has standards and well trotted paths for implementing them (at least a basic subset). [EDIT: I don't wish to spam the comments. If you wish to reply to this, please use the other thread you also replied to? I should have done it myself, sorry about that.]
treis 4y ago
>Would you be happy using a copy of jQuery 1.7 until all of Apple, Microsoft, Mozilla, and Google shipped 1.8 and all of your users upgrade I'd polyfill 1.8 until enough browsers support it like is done for every other browser api

deleted 4y ago

[deleted]