PHP is a tremendously popular language. An extensive portion of the internet runs on top of it. That includes any site based on popular Content Management Systems (CMS) like WordPress and Drupal, frameworks like Symfony and Laravel, and pure PHP sites.
However, when you think about PHP you may have in mind a server-side application. The number of environments in which you can run it is limited, isn’t it?
Imagine that you can now run PHP code in a new set of environments like a browser, serverless, edge, and even embedded in a different application. That opens a new set of possibilities for PHP.
At this point is when PHP meets WebAssembly.
WebAssembly, or Wasm, is a portable compilation target for different languages. Instead of compiling your code to Linux Arm64, you compile it to Wasm. The result binary uses a format that is platform-agnostic and optimized for size.
This module can run in any environment that includes a Wasm runtime (or Wasm Virtual Machine), like:
- Browsers: all major browsers include a Wasm runtime. You can expect your code to run on Chrome, Firefox, Safari, or Bing, including their mobile versions.
- Servers: there are several Wasm runtimes that focus on a server-side environment.
- Container runtimes: several container runtimes like containerd support WebAssembly modules, bringing the full power of Wasm to Kubernetes and other tools. For example, you can use popular tools like Docker to run and manage Wasm modules.
- Edge platforms: different companies like Cloudflare, Fastly and Vercel offer edge computing platforms that include a Wasm runtime.
- Embedded systems: there are Wasm interpreters that focus on really small devices. To be fair, not all of them will be able to run a PHP interpreter due to the resource limitations.
Some applications and even games use WebAssembly to extend their capabilities. A fantastic example is Microsoft Flight Simulator that allows people to extend it using plugins in WebAssembly.
Running PHP in WebAssembly opens the language to all these new use cases.
On the other hand, learning PHP used to require a local development environment and a web server, and that was very cumbersome for new developers.
WebAssembly opens a new set of possibilities. An astounding example is WordPress Playground. It uses WebAssembly to bring PHP and WordPress, almost everywhere:
- Browser: Interactive tutorials (like this one about WP_HTML_Tag_Processor) are now possible.
- Visual Studio code: setting up a WordPress development environment only requires installing a plugin.
- Mobile apps: Blocknotes is a note-taking application for iOS running an entire WordPress in WebView. The exact same WordPress site could be hosted as a web version of the app.
- Node.js: wp-now is an npm package that starts a WordPress development environment without the need for installing PHP, MySQL, or Docker.
- Edge servers.
The implications are profound!
Different devices, same WordPress
WordPress, a PHP CMS, won over 40% of the web as a non-portable server-side application. That was the beginning. These days, PHP runs as WebAssembly thanks to projects like WordPress Playground and PHP WASI.
Can you sense the magnitude of new opportunities here? Imagine WordPress as a note-taking app running on all your devices. Or as decentralized web apps running exclusively on edge servers or in blockchain. Or even offline-first websites running directly on your phone.
And the best part? It applies to all software, not just to PHP and WordPress.
Run different languages in WebAssembly
Other languages can take advantage of the same benefits as PHP. In VMware Wasm Labs, you can find a set of pre-compiled languages and libraries to WebAssembly. It includes languages like Ruby and Python, and popular libraries like SQLite.
You can run your Ruby or Python code without having to install any local interpreter. Just check the latest releases, download the module and start running your projects. This article teaches you how to run a Python application with WebAssembly.
Sharing libraries across different languages
WebAssembly enables PHP developers to use top-notch libraries built in other programming languages. After all, the same app can use many WebAssembly modules – it doesn’t matter which programming language they were originally built in. Imagine a PHP application that processes data using Pandas (a python library) and writes it to excel using Apache POI (a Java library) — all while running in a mobile app.
That’s an exciting future because today every language needs to provide its own bindings to call the low-level WebAssembly code. This is what the upcoming standard called Component-Model is looking to address. The goal of this standard is to simplify the composability between your application and multiple Wasm modules or components.
This proposal includes a new language to define the interface of a WebAssembly module. WIT, or WebAssembly Interface Types, provides a portable way of listing all the functions required and exposed by a WebAssembly module. With a WIT file, you would load a wasm module and call its methods directly – your runtime already knows what arguments and return type to expect.
And so, as the WebAssembly ecosystem evolves, you may start seeing Ruby developers building WordPress plugins using Jupyter Notebooks running on their tablets.
WebAssembly enhances security
Regular programs have the power to access the same resources as the user who runs them. It includes resources like files, intranet sites, computer memory, and everything else. In contrast, WebAssembly programs are fully isolated or sandboxed.
A typical malicious program running on your computer can read a file you have access to and send it to a remote server. However, a malicious WebAssembly program can only access that file if you gave it explicit access. You are in control and may choose to prevent that by running WebAssembly without disk or network access.
For example, the VMware Wasm Labs team analyzed a security issue in the Archive_Tar PHP library. A malicious attacker could prefix filenames with file:// inside the .tar archive and trick the library to overwriting unintended files upon extraction. Using it directly is risky, but you could mitigate the issue. Just run it as a WebAssembly module with file system access restricted to a single, empty, directory – et voila.
Similarly, WordPress Playground supports PHP 5.6 even though it no longer receives security fixes. The trick? PHP can’t mess with your files or your network because it doesn’t have any access.
Sandboxing is as much about security as it is about portability. A WebAssembly program cannot just assume it runs in an environment where a hard drive even exists. Maybe it’s running in a distributed immutable blockchain virtual machine? Or perhaps it runs on an embedded tracking device strapped to a sea turtle with no writable persistent memory? The WebAssembly standard doesn’t judge. It will support you in all cases.
The WebAssembly standard may sometimes seem overly limiting. It is low level, requires bindings for every module, and doesn’t offer direct access to system features. But that’s exactly what makes it so versatile. It provides a few well-defined features to support maximum flexibility and an incredibly large number of environments.
WebAssembly provides a few well-defined features to support maximum flexibility and an incredible large number of environments.
A few months ago, PHP was a server-side software with a steep learning curve. You had to download several tools and configure your environment before writing your first PHP script. Today, it’s a powerful, interactive, zero-setup language that can run — and bring its rich ecosystem — anywhere.
The WordPress Playground project is a great example. WordPress users and developers can now try themes, plugins and learn how to use it in a real instance without leaving their browsers. Everything without a change in the WordPress source code.
And this is just the beginning of what WebAssembly can achieve! Interoperable, sandboxed libraries running across the entire stack have the potential of changing how we think about creating software.
It’s time to start thinking about a consolidated and wider ecosystem.