storage-foundation-api-explainer

> Just a heads-up, the File System Access API is underway in Chrome, which potentially removes nearly all of the absurdity here. It doesn't. Because there are now 4 different file access api proposals. At least one of them is already in Chrome (File System Access). [1] Both Safari and Mozilla are unwilling to implement any of the four until the mess is cleaned up, and there's a single coherent proposal. Chrome, of course, doesn't care. Storage Foundation API in addition to File System Access they already implemented. [1] https://github.com/WICG/storage-foundation-api-explainer/iss...

I wrote that article 7 years ago, and FWIW I would side more with Dale these days. It's probably a good thing we didn't just slap a half-baked API on top of SQLite and call it a web standard. The biggest problem is that yeah, WebSQL tends to be faster than IndexedDB. Or at least it was back when I was working on PouchDB. Biggest issue IIRC was that joins were faster in SQLite than implementing the same thing in userland on top of IndexedDB. Browsers eventually shipped getAll/getAllKeys which also helped with cursor slowness. I haven't looked much at the Storage Foundation API [1], but it seems like a more reasonable approach moving forward. Just give developers the low-level tools and let them build SQLite on top of it. Also the Chromium devs have been working on relaxed durability, which apparently improves IDB perf in some scenarios [2]