3 ms·

I disagree, this is much better than WebSQL. WebSQL would have been tied to one specific version of SQLite, and developers would have to work to the lowest supp

I disagree, this is much better than WebSQL. WebSQL would have been tied to one specific version of SQLite, and developers would have to work to the lowest supported version. There would have been no extension mechanism. WASM SQLite is the correct solution. It’s extendable by the developer using it, they can uses SQLite extension modules, and build their own. But almost more so it proves the idea of a WASM db engine backed by a low level block FS api. We will see other db engines uses this architecture. DuckDB have already done it. I’m sure MongoDBs Realm and CouchBase Mobile will do the same soon too. We are in for an exciting time in the next few years.

modeless 4y ago
> WebSQL would have been tied to one specific version of SQLite, and developers would have to work to the lowest supported version. There would have been no extension mechanism. Why not? Web SQL would not be different from WebGL/GLSL or even JavaScript itself in that respect. Developers use feature detection and and work to the lowest supported version. APIs and languages can evolve, but in (mostly) backwards compatible ways. Extension and versioning mechanisms can be made. That's how the web works and Web SQL could have worked that way too. More broadly, you could apply arguments like this against everything in the entire web platform. Maybe everything should be a WASM module that developers could choose themselves! Image loading, video decoding, font rendering, DOM, JS engine, why not? It's actually a beautiful vision and I'd be all for it if not for cache partitioning. Every site would have to re-download and re-JIT an entire browser engine before it could do anything. The base platform needs to include a diverse set of commonly used features so that apps don't have to download the world, and on a list of ubiquitous libraries SQLite is right up there with other libraries backing the web platform, like zlib.
- samwillis 4y ago
  WebGL/GLSL is a low level API the equivalent of the OPFS api. Standardising WebSQL would be like browsers standardising on Three.JS rather than WebGL/GLSL. WebGL/GLSL give the developer a low level api to the graphics hardware. Video decoding apis talk to the hardware video decoding hardware. OPFS gives developers a low level API to the persistent file system / HDD / SSD.
  - modeless 4y ago
    The web platform has tons of very high level stuff in it, much higher level than SQLite, and more is being added. Even specifically on the topic of 3D, they're trying to add a <model> tag and standard 3D model file format to HTML right now. It doesn't make sense to reject Web SQL, which is much more foundational, on the grounds of being too high level. Not now, but even less so back when the decision was made in 2010, when the web itself was all higher level and the lower level APIs you mentioned didn't even exist.
    - nl 4y ago
      > they're trying to add a <model> tag and standard 3D model file format to HTML right now. To clarify, Apple made a proposal[0] which got no real traction. It has migrated[1] to a Javascript API[2] [0] https://github.com/WebKit/explainers/tree/main/model https://github.com/WebKit/explainers/tree/main/model [1] https://www.w3.org/community/immersive-web/ https://www.w3.org/community/immersive-web/ [2] https://github.com/immersive-web/webxr https://github.com/immersive-web/webxr
      - modeless 4y ago
        This is wrong. It moved to the immersive web CG but that doesn't mean it changed form to a JS API. It's just a venue change. The WebXR repo you linked is a different project entirely. The new location for <model> is here: https://immersive-web.github.io/model-element/ https://immersive-web.github.io/model-element/
  - haimez 4y ago
    All of these APIs are going to be very reliable fingerprinting opportunities, especially in combination. Keep that in mind when you think it’s going to be great for your web browser to also be a full featured application runtime.
    - nl 4y ago
      Don't hold back the one open platform there is (the web) with fingerprinting concerns when its competition (mobile platforms) require an identity to use them. The enemy of progress is perfect.
- FerociousTimes 4y ago
  > Every site would have to re-download and re-JIT an entire browser engine before it could do anything. Isn't this like a revival of the dreadful era of browser plug-ins from Adobe Flash Player to Java applets?
  - masklinn 4y ago
    No. The issue with flash and applets was not that you had to download stuff. It was that the security was non-existent (leading to the embedded runtime routinely crashing your browser), the interactivity was divergent from its surroundings, and the accessibility model was MIA. Also downloading 500K over 56k and over fiber or 5G are rather different propositions.
ilyt 4y ago
I'd still rather have basic SQL (that is enough for most) to just be there, for the apps where including SQL engine would be vastly more code than app itself. If we had block API and SQL (it could be just a concrete version running from WASM itself, to not bloat browser itself) it could save a lot on app size. App then could look at browser version and decide to use that or to download newest one to run.
sgbeal 4y ago
> WebSQL would have been tied to one specific version of SQLite, and developers would have to work to the lowest supported version. There would have been no extension mechanism. Not only that, but WebSQL disables a lot of mundane functionality, like the instr() SQL function and it's impossible to VACUUM because WebSQL requires explicit transactions and VACUUM cannot run in a transaction. i had the "pleasure" of having to work with WebSQL over the past couple of months for purposes of comparing its performance to the new sqlite features, and IMO, WebSQL is, as the kids say today, _weak sauce_. Its API is far too limited.
croes 4y ago
Unless frameworks and libraries start depending on it and each one of them uses different extensions. All of a sudden you have multiple slightly different instances running just because there isn't a standard.

modeless 4y ago

> WebSQL would have been tied to one specific version of SQLite, and developers would have to work to the lowest supported version. There would have been no extension mechanism. Why not? Web SQL would not be different from WebGL/GLSL or even JavaScript itself in that respect. Developers use feature detection and and work to the lowest supported version. APIs and languages can evolve, but in (mostly) backwards compatible ways. Extension and versioning mechanisms can be made. That's how the web works and Web SQL could have worked that way too. More broadly, you could apply arguments like this against everything in the entire web platform. Maybe everything should be a WASM module that developers could choose themselves! Image loading, video decoding, font rendering, DOM, JS engine, why not? It's actually a beautiful vision and I'd be all for it if not for cache partitioning. Every site would have to re-download and re-JIT an entire browser engine before it could do anything. The base platform needs to include a diverse set of commonly used features so that apps don't have to download the world, and on a list of ubiquitous libraries SQLite is right up there with other libraries backing the web platform, like zlib.

samwillis 4y ago
WebGL/GLSL is a low level API the equivalent of the OPFS api. Standardising WebSQL would be like browsers standardising on Three.JS rather than WebGL/GLSL. WebGL/GLSL give the developer a low level api to the graphics hardware. Video decoding apis talk to the hardware video decoding hardware. OPFS gives developers a low level API to the persistent file system / HDD / SSD.
- modeless 4y ago
  The web platform has tons of very high level stuff in it, much higher level than SQLite, and more is being added. Even specifically on the topic of 3D, they're trying to add a <model> tag and standard 3D model file format to HTML right now. It doesn't make sense to reject Web SQL, which is much more foundational, on the grounds of being too high level. Not now, but even less so back when the decision was made in 2010, when the web itself was all higher level and the lower level APIs you mentioned didn't even exist.
  - nl 4y ago
    > they're trying to add a <model> tag and standard 3D model file format to HTML right now. To clarify, Apple made a proposal[0] which got no real traction. It has migrated[1] to a Javascript API[2] [0] https://github.com/WebKit/explainers/tree/main/model https://github.com/WebKit/explainers/tree/main/model [1] https://www.w3.org/community/immersive-web/ https://www.w3.org/community/immersive-web/ [2] https://github.com/immersive-web/webxr https://github.com/immersive-web/webxr
    - modeless 4y ago
      This is wrong. It moved to the immersive web CG but that doesn't mean it changed form to a JS API. It's just a venue change. The WebXR repo you linked is a different project entirely. The new location for <model> is here: https://immersive-web.github.io/model-element/ https://immersive-web.github.io/model-element/
- haimez 4y ago
  All of these APIs are going to be very reliable fingerprinting opportunities, especially in combination. Keep that in mind when you think it’s going to be great for your web browser to also be a full featured application runtime.
  - nl 4y ago
    Don't hold back the one open platform there is (the web) with fingerprinting concerns when its competition (mobile platforms) require an identity to use them. The enemy of progress is perfect.
FerociousTimes 4y ago
> Every site would have to re-download and re-JIT an entire browser engine before it could do anything. Isn't this like a revival of the dreadful era of browser plug-ins from Adobe Flash Player to Java applets?
- masklinn 4y ago
  No. The issue with flash and applets was not that you had to download stuff. It was that the security was non-existent (leading to the embedded runtime routinely crashing your browser), the interactivity was divergent from its surroundings, and the accessibility model was MIA. Also downloading 500K over 56k and over fiber or 5G are rather different propositions.

ilyt 4y ago

I'd still rather have basic SQL (that is enough for most) to just be there, for the apps where including SQL engine would be vastly more code than app itself. If we had block API and SQL (it could be just a concrete version running from WASM itself, to not bloat browser itself) it could save a lot on app size. App then could look at browser version and decide to use that or to download newest one to run.

sgbeal 4y ago

> WebSQL would have been tied to one specific version of SQLite, and developers would have to work to the lowest supported version. There would have been no extension mechanism. Not only that, but WebSQL disables a lot of mundane functionality, like the instr() SQL function and it's impossible to VACUUM because WebSQL requires explicit transactions and VACUUM cannot run in a transaction. i had the "pleasure" of having to work with WebSQL over the past couple of months for purposes of comparing its performance to the new sqlite features, and IMO, WebSQL is, as the kids say today, _weak sauce_. Its API is far too limited.

croes 4y ago

Unless frameworks and libraries start depending on it and each one of them uses different extensions. All of a sudden you have multiple slightly different instances running just because there isn't a standard.