Building a Browser-Based Coding Playground with PHP WebAssembly

One issue with WebAssembly is bundle weight. The runtime itself is not something I want to load unnecessarily when a user only wants to work with HTML, CSS, or JavaScript.

So I kept the PHP execution environment separate from the initial application experience.

The PHP runtime is loaded dynamically when PHP execution is required. That means the playground can start without immediately loading everything required for PHP execution, and the heavier runtime is introduced when the user actually needs it.

This was essential for keeping the general playground experience fast, responsive, and lightweight on both desktop and mobile.

A real PHP project is rarely a single file. I therefore wanted the playground to support a project structure rather than only executing one isolated PHP snippet.

For example: index.php and helper.php, where index.php can use functions or classes from helper.php.

The WebAssembly environment provides an in-memory virtual filesystem (VFS) for the PHP runtime. The playground places the project files into that virtual environment before execution.

So when PHP executes require 'helper.php', the PHP runtime can resolve that file inside its virtual environment. This makes the playground much closer to working with a small real-world PHP project rather than a toy snippet executor.

// Virtual Filesystem (VFS) Project Tree
project/
├── index.php    // require 'helper.php'; echo formatUser($user);
└── helper.php   // function formatUser($user) { return htmlspecialchars($user); }

Moving PHP execution to the browser does not mean that WebAssembly magically makes arbitrary code safe. The important benefit is different: I no longer need to take arbitrary PHP source code and execute it on my own server.

That removes an entire class of server-side concerns from the architecture.

If I had chosen server-side execution, I would have had to maintain a strong isolation boundary around every execution request and continuously think about what the submitted PHP could access.

With client-side execution, the user's code remains inside the browser's execution environment. The browser already provides an important security boundary between web applications and the user's operating system, and WebAssembly execution takes place within that browser environment.

This does not remove every possible security concern, but it significantly reduces what I need to expose and protect on my own infrastructure.

Running a PHP runtime through WebAssembly has limitations compared with running PHP on a dedicated Linux server. There are differences in:

So this is not intended to replace a real PHP development or production environment. The purpose is different: a convenient, zero-friction environment for learning, experimenting, testing examples, and quickly trying PHP code without setting up a PHP server.

• Available PHP extensions (C extensions requiring OS shared libraries are not bundled)
• Operating-system access and low-level system call boundaries
• Network behavior (outbound raw TCP sockets cannot be opened directly from browser WASM)
• Filesystem behavior (in-memory virtual filesystem resets on page reload unless exported)
• Browser resource limits and tab thread constraints for heavy jobs
• Initial runtime loading bandwidth on slower connections