wordpress-playground

> Or you could just use publii, an office suite of your choice, or type bad html and css by hand, then pass raw files on very cheap hosting providers, enjoying a clunky, and sometimes ugly, "website". WordPress folks are working to enable static generation using WordPress Playground. It will work pretty much like Publii does today. https://github.com/WordPress/wordpress-playground/issues/707

Sorry friend, WordPress already beat you to it: https://github.com/WordPress/wordpress-playground

Ah but that's not what I am referring to. If you take a look at Vercel Postgres page [^0], you will see that Vercel is marketing a new way of writing server side rendered code, where you can write SQL code right next to the HTML-ish code for the frontend. So I'm just merely making a (meant to be humorous) comparison with PHP. > PHP can't run in the browser. Well actually, WordPress did it [^1] [^2]. They compiled PHP to WASM, so you can run our favorite web framework in your own browser. I see your point anyway. Systems evolve. Tooling has to follow suit. PHP cannot achieve some of the feat today mega stack can. The problem arises when we apply the latest bleeding edge technology meant for systems that have to serve millions into our little MVP that may have less than 1000 users in your first few years. [0]: https://vercel.com/storage/pos

> Is there a reason why using OPFS directly from SQLite doesn't work? I'm guessing this means using SQLite WASM's built-in OPFS integration as described in these articles: - sqlite3 WebAssembly documentation - Persistent Storage Options: OPFS - https://sqlite.org/wasm/doc/trunk/persistence.md#opfs - SQLite Wasm in the browser backed by the Origin Private File System - https://developer.chrome.com/blog/sqlite-wasm-in-the-browser... Within the Playground, SQLite interacts with the database file in MEMFS only, and the Playground coordinates the syncing from MEMFS to OPFS. https://github.com/WordPress/wordpress-playground/tree/trunk... The reason for this, I believe, is that the primary use case is/was to have the entire file system in memory, including SQLite's database file. This was the original implementation, and is still the default beh

There is partial support for persistence, for browsers that have origin private file system (OPFS) implemented. > OPFS is only supported in Chrome-based browsers at the moment like Edge, Android browser. Safari and Firefox users won't be able to benefit from this feature yet Persistent Playground: Sync between MEMFS and OPFS - https://github.com/WordPress/wordpress-playground/pull/546

It's very interesting to me since I have an interest in porting various hitherto "server-side" applications to run in-browser. Doubly interesting because it's the first real product I've seen running SQLite -- so far I've only seen toy demos. But, wondering about something -- poking around in the code a bit, and realizing I know next to nothing about present-day php, I realized this may be not using the "traditional" SQLite-over-OPFS approach to get persistence? Actually, after a bit more reading it's not clear to me that persistent storage is available yet via Emscripten. And after yet more poking around I found: https://github.com/WordPress/wordpress-playground/issues/19 which I guess means that persistence isn't yet possible for WP in the browser :(

It would be helpful if you could report this to the issue tracker. https://github.com/WordPress/wordpress-playground/issues

The team behind this tried to deploy to Cloudflare but hit memory constraints with Workers due to the 128MB limit there: https://github.com/WordPress/wordpress-playground/issues/69 There’s likely more work that could be done to make this viable, though (or Cloudflare could raise limits).

Note WordPress has an official WebAssembly build for the browser and Node.js: https://developer.wordpress.org/playground https://github.com/WordPress/wordpress-playground Disclosure: I'm the creator This project is different in that it builds PHP to WASI.

I love the work going on there at WasmLabs, especially enjoying the articles with in-depth technical explorations. After the article about running WordPress in the browser was published, there's a new project called WordPress Playground which is gradually preparing NPM or Composer packages to make it easier for people to run it. https://github.com/WordPress/wordpress-playground/ They've been doing very detailed work, like making some patches to PHP and SQLite for improved compatibility with Emscripten, etc. It seems there's a lot of overlap with what WasmLabs has achieved and probably have continued to develop further. Perhaps there's an opportunity for collaboration.

Thank you for sharing! I just created an issue: https://github.com/adamziel/wordpress-wasm/issues/19