SQLite Wasm in the browser backed by the Origin Private File System

I think this will be great for extensions. Currently the only solid choice is to use the dead simple storage.local which only allows to retrieve things by ID.<p>There&#x27;s one problem though, this new API is for the web, so the nature of this storage is temporary - obviously the user must be able to clear it when clearing site data and this what makes it currently an unviable solution for a persistent extensions data storage. <a href="https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=1383216" rel="nofollow">https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=138321...</a>

Does anyone have hands-on experience with how well different browsers support this? This blog post and caniuse both say Chrome support is currently somewhat limited (though being improved); caniuse also mentions that Safari (both desktop and iOS) only support the Origin Private File System part of the File System API, and that Firefox doesn&#x27;t support it all. I&#x27;m curious how all that actually shakes out in practice.

This is a nice overview!<p>Discussion from back when the SQLite project announced this last year: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33374402" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33374402</a><p>There isn&#x27;t an &quot;official&quot; NPM package or ES6 model yet, but I believe they are working on it. It&#x27;s also very much designed for the browser currently, but again I believe they are intending to support server WASM environments too eventually.

TIL OPFS.<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;File_System_Access_API#origin_private_file_system" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;File_System...</a><p>What&#x27;s next, mmap() for javascript?

The custom header requirement will make this version of sqlite unusable for many usecases. Can SQLite fallback to using slower persistant APIs if neither Cross-Origin-Opener-Policy or Origin-Embedder-Policy are set? If not, does the SQLite project intend to provide a version that would?<p>Devs who don&#x27;t need the high performance but want wider compatibility will probably continue to use the &quot;unofficial&quot; versions.<p>Also, last I checked, you could definitely load web assembly in a page that has a File:&#x2F;&#x2F;&#x2F; origin.

Very nice. I hope Firefox end up supporting OPFS.<p>My use case is an entirely offline webapp that I&#x27;m building as a side project, partly just to see what is possible. I&#x27;ve tried indexeddb, pouchdb, absurd-sql, and various others, and have ended up back at localstorage, which is plain but low on edge cases.<p>The other big pain point I am hacking around is cross device sync; I&#x27;m leaning towards simple chrome and firefox extensions that&#x27;ll slurp data into your profile in order to sync, which&#x27;ll work for cross computer sync for my needs. However, chrome on android doesn&#x27;t support extensions, and there&#x27;s no other good way that I&#x27;ve found to sync between a user&#x27;s chrome profile and android, so that is still a hole in the story. Some kind of webrtc based thing is imaginable, but it&#x27;s clunky.

Fun fact: The headline image is the Stadtbibliothek Stuttgart, the nicest library I ever visited: <a href="https:&#x2F;&#x2F;www.archdaily.com&#x2F;193568&#x2F;stuttgart-city-library-yi-architects" rel="nofollow">https:&#x2F;&#x2F;www.archdaily.com&#x2F;193568&#x2F;stuttgart-city-library-yi-a...</a>

Ironically I was just about to drop in absurd-sql [1] to a project, which uses indexeddb to back SQLite. This seems better.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;jlongster&#x2F;absurd-sql">https:&#x2F;&#x2F;github.com&#x2F;jlongster&#x2F;absurd-sql</a>

This is honestly very cool. VS Code uses a similar approach to their local file system provider, albeit with a wrapper around IndexDB instead of SQLite. There’s some interesting trade offs too, since IndexDB can store the browser’s native file handlers in a flat map — so there’s no need for a schema.<p>IMO, the Chrome team is being a bit deceptive with their phrasing on synchronous file handles. The problem is that the entire API is wrapped up in an asynchronous ceremony. `createSyncAccessHandle` is only available in a worker context. So you can only communicate with the worker using an asynchronous postMesssage event dispatcher. And even when you’re in the worker, file handles can only be accessed through methods that return a promise.<p>I understand the need for such boundaries when working with a single threaded language, but limiting the synchronous APIs to just workers seems like one too many layers of indirection. I recently attempted to write a POSIX-style BusyBox library and this sort of thing was a total show stopper.

I have yet to see whether implementations allow users direct access via the filesystem to these contents. The idea of each origin having some files sounds fine. But if I genuinely want to help &amp; empower my users, give them the most user agency, I&#x27;d want them to be able to access the sqlite sb themselves directly, with whatever hazards they thereby assume.

Using SQLite in the browser is great until you have users that open your app in more then one browser tab.

I was so disappointed when sqlite&#x2F;websql was ditched in favour of IndexedDB. What were they thinking? Too smart for their own good?

Does anyone have a good idea of when OPFS will be broadly available in all major browsers? And what&#x27;s best to use as a pseudo-polyfill in the mean time?<p>Something relevant is absurd-sql, but unfortunately that&#x27;s not even close to production ready :&#x2F;<p><a href="https:&#x2F;&#x2F;github.com&#x2F;jlongster&#x2F;absurd-sql">https:&#x2F;&#x2F;github.com&#x2F;jlongster&#x2F;absurd-sql</a>

I wanted to use it in a chrome extension worker, but sync version of OPFS isn&#x27;t available in that context. Hope this gets fixed.

Interesting. Looks like the data persisted to disk should be available for opening via traditional SQLite GUI tools too (eg sqlitebrowser.org), though Chrome&#x2F;Chromium would probably need to be not running at the same time for safety.

The sqlite.wasm is 683kB and the sqlite.js is 300kB. So is it supposed to be used in PWA context where these files are cached? Why no one is talking about CAP here. Is it real-production-ready?

we could call it WebSQL

what is exactly the use case for this?

Let&#x27;s hope Firefox starts to support the File System Access API soon.<p>For me, it is the last missing piece to make web apps as comfortable as native apps.<p>I use a lot of web apps I fine-tuned exactly to my liking. I do all my writing in this web app for example: <a href="https:&#x2F;&#x2F;www.gibney.org&#x2F;writer" rel="nofollow">https:&#x2F;&#x2F;www.gibney.org&#x2F;writer</a> - I hit F11 and boom! I am in distraction free writing heaven :)<p>If Firefox would support the File System Access API, it would be much more comfortable to load and save my writings.

The Web SQL standard was deprecated (by Mozilla) on the grounds of a single implementation.<p>The result today: A single SQL implementation with no standard (beyond SQLite) and therefore no easy way for anyone to create a compatible alternate implementation.

Cybersec is like &quot;here we go again&quot;

Yay. More ways for people to force webapps upon us.<p>I miss when the web was essentially a document viewer.