[tracker1]

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.

[wtatum]

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.

[tracker1]

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.