[dmsnell]

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.

[JustLurking2022]

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.

[adamziel]

Docker works on the server, WASM WordPress works in the browser. The innovation is that you don't need a backend.

[JustLurking2022]

"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.