Some ideas for persisting the SQLite database in IndexedDB: https://github.com/jlongster/absurd-sql
Thank you for sharing! I just created an issue: https://github.com/adamziel/wordpress-wasm/issues/19
WordPress WASM
61–69 of 69 posts
Re: WordPress WASM
#62I'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
Author here, here's an in-depth writeup on how this works and why it's useful:
https://make.wordpress.org/core/2022/09/23/client-side-webas...
To answer your questions directly:
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.
Re: WordPress WASM
#63Author here, it is super encouraging to see this trending on HN, thank you for the great discussion, links, and ideas!
I hope to change how learning, using, and contributing to WordPress looks like. This writeup explores how WASM WordPress works and why it's useful:
https://make.wordpress.org/core/2022/09/23/client-side-webas...
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.
Re: WordPress WASM
#64Earlier quoted context omitted.
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…
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.
Docker works on the server, WASM WordPress works in the browser. The innovation is that you don't need a backend.
Re: WordPress WASM
#65Earlier quoted context omitted.
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? 2.) How are unique constraint violations handled?
Don't use auto-increment. Use a ULID or some other algorithm driven PK
ULID was new to me. It's quite interesting https://github.com/ulid/spec
Re: WordPress WASM
#66For those wondering about the "why", this post details the motivation: https://make.wordpress.org/core/2022/09/23/client-side-webas... 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.
Pretty amazing to get all of PHP working in WASM. Next maybe we can get full MySQL, too (like the Crunchy Postgres port [0] [1]). Would also love to see it for Java, Go, Perl, Sed, and Awk :) What if Intelli-J could run in the browser? Yes please. I bet some of these even already exist. What a time to be alive, 15 years ago I'd never have guessed Javascript could evolve into this! [0] https://www.crunchydata.com/blog…
Is it my turn to post this prophetic talk? https://www.destroyallsoftware.com/talks/the-birth-and-death...
Re: WordPress WASM
#67Re: WordPress WASM
#68This 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.
Static site generators require a headless CMS and all the headless CMS I tried are much harder to use and way less flexible then WordPress.
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.
Re: WordPress WASM
#69Earlier quoted context omitted.
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.
Docker works on the server, WASM WordPress works in the browser. The innovation is that you don't need a backend.
"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.