WordPress, WooCommerce and Laravel in your tab

Open play.loxodon.org and you get WordPress, with wp-admin and the block editor, or a WooCommerce store with a working checkout, or a Laravel application, running inside the tab. There is no server behind the pages. After the first download, every request is answered by JavaScript in a Web Worker in your browser.

What is actually happening

• The PHP was compiled, once. Loxodon’s build turned every PHP file of WordPress (1,530 of them) into an ES module. The browser downloads them packed in parts, the 520 modules the front page needs first (4.5 MB compressed) and the rest behind, and evaluates a module the first time a page includes it. A front page touches about 540.
• The runtime is the same one Cloudflare runs. The worker host that serves this site from a Durable Object is the host running in your tab. Its database interface is filled by SQLite compiled to WebAssembly, stored in the browser’s private file system, so your changes survive a reload.
• A service worker plays web server. The page’s navigations, forms and REST calls are intercepted and handed to the worker, which runs index.php with PHP-FPM semantics and returns a response. Static files come straight from the CDN, as Workers assets do in production.
• Files WordPress reads are fetched on demand. Theme templates, block styles and translations are read as files by the PHP code; the browser fetches each one the first time it is needed, and the ones a crawl proved necessary come in a single small pack.
• Generated PHP compiles in the browser. Blade writes compiled views as PHP files at run time. The compiler ships with the host, so a file no build could have known about is compiled on first include.

Why build it

Partly because it is the most direct proof of the claim: a WordPress site with no PHP interpreter anywhere, not even one compiled to WebAssembly. Mostly because it is a testbed. The browser’s engine is the same V8 that runs on Cloudflare, so a sampling profile of the worker while it serves a WordPress page shows exactly where the compiled code spends its time, function by function, with the PHP names mapped back. Those profiles are what the runtime’s performance work is measured against, and clicking through wp-admin in a browser has already found bugs that no test suite had reached.

What it is not

Not a development environment: for that, the Node host has the real filesystem, processes and network, and it compiles on first use already. Firefox works since the runtime learned to read formatted stack traces where V8’s call-site API is absent; Safari should too, but it is untested. And not fast on first visit: the download is what it is, though it is cached afterwards.

The whole thing is a few hundred lines of glue around the same host that serves this page. Which is rather the point.