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]

> There's even recent work to add even higher performance APIs into the Filesystem Access API and the reception from Firefox and Safari has been positive. Positive as in: "FileSystem Access is a significant security risk and we're not going to implement this"? https://www.chromestatus.com/feature/6284708426022912 Positive as in "No, we don't want fifteen different file access apis, and we don't think Storage Foundation API is going anywhere"? https://www.chromestatus.com/feature/5670244905385984 And even though this is a draft created and authored exclusively by Googlers, even other Googlers are confused: https://github.com/WICG/storage-foundation-api-explainer/iss...

IndexedDB does indeed suck, but there's really no alternative to it if you want Safari and Firefox support. Fortunately, in Chrome we have the FileSystem Access API which has a feature that lets you write into an "origin private" store, similar to how IndexedDB partitions storage per origin. There's even recent work to add even higher performance APIs into the Filesystem Access API and the reception from Firefox and Safari has been positive. Really early work is happening here: https://github.com/WICG/storage-foundation-api-explainer and the latest proposal is here: https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUV...

i think it's changed names (maybe) since i've last seen it? but here is the low level io spec: https://github.com/WICG/storage-foundation-api-explainer