Hacker News Reader

Comment by JustLurking2022 | Hacker News Reader

JustLurking2022

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.

View on HN

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.

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.

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.

Reply on news.ycombinator.com