Hacker News Reader

Comment by jt2190 | Hacker News Reader

WebSQL was a proposed web standard that all standards-compliant browsers would have to implement. The standard was tightly coupled to the SQLite implementation, which was a problem for any browser that could not just bundle SQLite. Ultimately the standard was rejected because it was too coupled to a single implementation.

View on HN

Maybe as a standard it was lacking... but iirc Firefox, Safari and Chrome all had support, and IE/MS was the one holdout. I get that it was too "loosely" defined as a Standard.

I also think the UX for WebSQL isn't great and a modern async/promises based interface would have been better (even if queries themselves non-blocking and serialized on another thread). Combined with the File System Access API, this could be really useful though.

Currently toying with a Rust/Tauri project, and debating on using the SQLite plugin to do the data access in the UI, or in the rust side, then serialize the requests across more manually. Since I'm dealing with other services, will have to do a lot of that anyway.

Also using Tauri in SQLite for a project. I only briefly looked at the provided SQLite plugin and quickly decided it didn't support everything I needed (custom scalar functions for example but there were others) but as far as I know all "official" Tauri plugins use the same event/command RPC mechanism available to you in userland for calling into Rust so I don't actually think the Tauri SQLite plugin "does the access in the UI" in the truest sense -- otherwise it wouldn't be a Tauri plugin it would just be a vanilla JS lib.

If you've looked more closely and know that not to be the case would like to hear what you've seen but my understanding is that anything that leaves the WebView sandbox is using RPC to make calls to Rust.

I'd be surprised if it was anything other than what I can do myself via the existing event/command system... I just meant that controlling the queries themselves on the JS side vs. the Rust side... kind of torn between something similar to a regular web api, abstracted over events, etc. Honestly, I should just start doing anything at this point... started over this past weekend, and got some hello world bits pretty quickly and been mostly toying since.

> The standard was tightly coupled to the SQLite implementation…

I don't understand why this is a problem. It's in literally everything but my browsers, is 1/18th the size of Apple's home page (500 KB, while Chrome is a 1GB binary on my machine), and is tested far better than any browser.

> …which was a problem for any browser that could not just bundle SQLite.

What's a scenario where a browser can't just bundle SQLite?

Firefox already used SQLite internally for history as well, I wonder if any other browsers do the same.

Mozilla's explanation for not supporting Web SQL:

"Beyond HTML5: Database APIs and the Road to IndexedDB" (June 2010) https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

Reply on news.ycombinator.com