I think this is a really compelling pattern for converting traditional server rendered apps to be offline enabled (or choosing to build new ones this way). I have seen similar examples using Python.
Initially these are more of a “backed data” type app, with no offline public writes. [0]
The next step is to have local/offline SQLite to server syncing, enabling writes while offline that are synced back to the server on reconnection. This would inherently be eventually consistent and brings its own issues with relational data integrity, however the SQLite Session Extension could be I good way to build such a system [1]
The alternative is a new data store based on CRDTs (conflict free merging of offline edits), there are some exciting developments happening in that area. I have seen it suggested that the SQLite session extension is almost a crdt if you squint at it.
This is certainly a cool idea, but I don't understand a few things about how reality would work with an async reconciliation process on the database layer:
1.) How would the auto-incremented ID fields be merged in such a system?
I really like this idea. Distributed, loosely-coupled content creation & management that syncs up with "everyone else" on a time scale of minutes or hours.
Basically for learning/interactive tutorials, trying out something quickly in different PHP versions (which is cumbersome right now), secure and easy demos for themes and plugins.
Here's a few possible applications: try a theme without affecting your current website, have live themes and plugins demos right in the directory, enable first contributions directly on wordpress.org without any setup steps, learn WordPress in the browser, or replay and debug failed tests right in the CI.
Technically most of these things are possible today with a specialized backend. The problem is that it's either expensive and time-consuming to maintain, like a fleet of custom WP instances, or limited, like iframing a preconfigured 3rd party solution. WASM-based solution is open-source, cheap to run, and doesn't seem to have deal-breaking limitations.
I wouldn't run production websites on this just yet, as it sometimes crashes in Chrome and the bundle size is 50MB+, but both problems can be solved. Once they are, this will be so much more than just a cool tech demo.
People are already using Chrome or Chromium-based browser all over the world. VSCode, Spotify, Teams, Slack, Figma and many others use Electron or CEF which are based on Chromium. It is not necessarily going to be a bigger risk what what we have now.
And I am sure a severe bug in Qt will also affect almost everyone, no different from the Chromium situation. And I trust the Chromium/Electron community more than the random "another cross-platform UI framework" that pops up on hacker news that probably will not be maintained in a year. (I am some people don't like this sentence but they have to face the fact.)
So from user perspective, they still have to run it like they would run local web server but more secure? It's improvement security wise, though it's still hustle for app distribution right?
> Add an app store and the web will have finished becoming the platform that everyone has been suspecting it is.
Basically what we need now is a user-side "app store" that downloads apps packaged as WASM and runs them!
Honestly this setup could probably work today, use something like Tauri[0] to build a simple app-store like experience. When someone installs an app, this thing downloads the WASM, and runs it with the necessary linked modules (local file access, network).
Then, you can spin up a new window that is the new application, and keep it running/do whatever else users would expect. I mean you could even launch the apps standalone/separate processes as well so that people can close the original one (or put it to tray, whatever).
This could easily be like snap/flatpak but even better in some ways. Browser technology is almost assured to always be moving forward and getting more powerful/impressive because of the large interests involved.
The tldr, is that AbsurdSQL uses IndexedDB to make WASM SQLite ACID compliant. The alternative is to pause writes and dump the whole db as a string to indexeddb, very slow, and not durable.
AbsurdSQL is an incredible hack, but is a hack at best.
There is a new api, File System Access and the “origin private file system”[0], coming to browsers that has been design specifically with WASM SQLite in mind. I believe the Chrome team have been collaborating with the SQLite team to ensure it will work well. Once this drops it’s going to bring a lot of innovation.
I'm too dumb to understand how would this work. Can anyone explain please. Wordpress server side is where all the magic happens data is stored and retrieved from the database. How would it look like in wasm? Will the wasm communicate with database? If so wouldn't it expose db credentials? What would the backend look like? I have so many questions
There is no backend: the database itself is SQLite in WASM living in the user's own browser.
This is more of a tech demo and test environment than something that would work as an alternative to server-side WordPress - since if you are using a CMS you generally want the results to be visible to people other than you!
WebAssembly is the magic sauce that transforms server-side code into client-side code. MySQL unfortunately is not yet supported by WebAssembly, so I applied a plugin that adds SQLite supports to WordPress [0]. The WebAssembly application has its own in-memory filesystem that lives in a specific browser tab and is scraped as soon as you close it.
So – technically it exposes db credentials, and even the entire DB, but that you are the only user of that DB so it's okay.
> What would the backend look like
The only backend is a static file server where the code and the database live. Your browser downloads a copy of the database and allows you to modify it in the current tab, but the updates are never saved back to the server.
A very very interesting addition would be to add the ability to fetch data from a remote WP website's APIs.
In this way the server could serve a cached page on first request, then the wasm file would be downloaded. From then the whole rendering could be client side, while still fetching data from the remote DB. This could significantly speed up things for users.
This is amazing for security, you’ll just need to hook the file system calls and block FS writes at the wasm bridge level.
It won’t prevent obvious security bugs in the PHP code though, which arguably is the most important attack vector for spammers trying to post stuff on your WordPress installation
This seems like a "can't see the forest through the trees" project. If you don't want to run a server, there's no need for WordPress in the first place - just use a static site generator, or a SPA that uses static content as the backend. Have done a lot of WordPress development, and I love it, but it doesn't seem like it fits this use case better than other options.
As noted above seven hours before your comment ;) the purpose for this project is for embedding interactive WordPress installations in documentation and to provide a playground in the browser for testing code or learning how to write plugins, etc...
The forest is shrinking the time and distance between code we care about and visualizing the results. WASM and an in-browser environment is the tree. Even for experienced devs it's not always readily available to have a web server, PHP, a database, and WordPress running where you can quickly make a change and test it out or demonstrate it to others.
This makes it possible to ship a WordPress site as a demo site (with pre-filled content and structure) where anyone can show off their WordPress plugin or theme without needing to have a backend or worrying about securing it.
It's a solution in search of a problem. I've got self contained environments in Docker containers that accomplish all of that without introducing a couple extra runtime layers to have to debug.
"Server" is a false distinction in this context, as I run it on my desktop - and can do so across Windows, Linux or Mac. So, for the developer workflow use case - what benefit do I really get by running it in the browser? There we are, back to it being a solution without a problem.
Aside from that - this thing uses SQLite for a specific reason - the browser can't connect directly to a remote DB, so any content you create in this instance is visible to precisely no one else. As such, it's certainly not an answer to actual publishing use cases either.
I mostly agree - but running WordPress in a browser doesn't actually solve any of those issues - it's not intended for hosting anything publicly visible, as it can't persist to a remote DB. To make it capable of doing so, ou would likely end up with a server layer somewhere, minimally to manage authz, which puts it back in the realm of equivalent to a SPA.
First thing that came to mind is that I could load this up on a static host, saving content in a local SQLite (or even in SQLite in S3), make changes and then export the results to S3 as static HTML files. All without ever running any PHP/SQL host. One could technically upload this to GitHub Pages.
This just replaces the frontend framework written in JS with a frontend framework written in PHP compiled via wasm. It doesn't eliminate the need for something to manage views and state on the front end, as that's where you're executing all of your code now?
Just wait what things on top of that WP-PHP people will come up with. This thing will blind enough people with the looks of "modern and shiny", that they might create something similarly vulnerable and mistake prone to original WP plugins. I mean, someone must be writing these plugins ... shudders
Initially these are more of a “backed data” type app, with no offline public writes. [0]
The next step is to have local/offline SQLite to server syncing, enabling writes while offline that are synced back to the server on reconnection. This would inherently be eventually consistent and brings its own issues with relational data integrity, however the SQLite Session Extension could be I good way to build such a system [1]
The alternative is a new data store based on CRDTs (conflict free merging of offline edits), there are some exciting developments happening in that area. I have seen it suggested that the SQLite session extension is almost a crdt if you squint at it.
0: https://simonwillison.net/2021/Jul/28/baked-data/
1: https://www.sqlite.org/sessionintro.html