FrankenWasm - WebAssembly plugins

[johanjanssens]

I gave a talk at ConFoo Montreal last week about building PHP extensions with WebAssembly. The idea: write plugins in Rust, Go, or JavaScript, compile to .wasm, and call them from PHP through a simple class, no C, no FFI, no shelling out.

The approach: a FrankenPHP\Wasm PHP class backed by a C extension that bridges PHP → Go → Extism → Wazero. Plugins are sandboxed .wasm files discovered at startup. Each HTTP request gets its own plugin instances, fully thread-safe.

$md = new \FrankenPHP\Wasm('markdown-rs');
$html = $md->call('convert', '# Hello World');

$jsx = new \FrankenPHP\Wasm('jsx-include');
$rendered = $jsx->call('render', [
    'script' => 'function App(props) { return <h1>Hello, {props.name}!</h1> }',
    'props'  => ['name' => 'FrankenWASM'],
]);

Wasm::list();      // ['markdown-rs', 'chroma', 'sanitize-rs', ...]
Wasm::metadata();  // [{name: 'markdown-rs', file_size: 644000}, ...]

PHP data in, PHP data out, arguments are automatically JSON-encoded, and if the plugin returns JSON it's decoded back to PHP arrays/values. Anything you can json_encode() works as input.

The repo has 20 plugins across three languages, from a 256 KB ASCII art generator in Rust to a 7 MB React JSX server-side renderer in JavaScript. A few highlights:

Plugin	Language	Size	Time
markdown-rs	Rust	644 KB	~1 ms
sanitize-rs	Rust	1.2 MB	~0.8 ms
scss-rs	Rust	2.7 MB	~0.2 ms
chroma	Go	8.3 MB	~6 ms
jsx-include	JS	7.0 MB	~0.8 ms

Writing a plugin is minimal, here's a complete Rust HTML sanitizer:

use extism_pdk::*;

#[plugin_fn]
pub fn sanitize(input: String) -> FnResult<String> {
    Ok(ammonia::clean(&input))
}

Compile, drop the .wasm in the plugins directory, done. Same pattern for Go and JS with their respective Extism PDKs.

Like FrankenAsync, this requires the same little fork that adds frankenphp.Thread(index) and frankenphp_thread_index() to reach the request context from a C extension. Everything else uses upstream FrankenPHP, including RegisterExtension.

• Slides (ConFoo 2026): https://gamma.app/docs/Building-PHP-plugins-with-WASM-Confoo-2026-j0k4fwetfc6gjib
• Code: https://github.com/johanjanssens/frankenwasm

[dunglas]

Awesome work!

Would you mind opening a PR to expose the fun in you need? We'll be glad to merge it.

[johanjanssens]

Thanks Kevin, much appreciated, promised you this a year ago. Will open PR's for some of the smaller things this needs to work, first need to finish my keynote at DPC, which is all about FrankenPHP :)

[johanjanssens]

All done, 2 PR's:

• feat: expose thread API for Go-based PHP extensions #2305 (this is the key one)
• perf: replace platform-specific CPU/memory probing with gopsutil #2306

[henderkes]

Now this one is even more fun than the last one! I think you've more than proven how useful directly reaching out to php threads can be, so we really should merge in the changes.

[johanjanssens]

Thanks Marc, will get this changes ready for review in a PR. This isn't all the fun by the way, got a few more coming ;)

[nickchomey]

how would this compare to using Extism's php sdk?

[henderkes]

This uses a statically linked extism runtime so no libraries need to be installed on the host to be called with FFI.

[johanjanssens]

The PHP SDK uses FFI to call into libextism, which is Extism's own shared library. Under the hood, libextism is built on Wasmtime. The dependency chain is: PHP SDK → (FFI) → libextism → Wasmtime

With FrankenWASM you get: PHP → C/Zend → CGO → Go/Wazero/Extism

All in one process, compiled into a single binary. No shared libraries to install, no FFI extension to enable, you get a PHP runtime you can drop anywhere and extend with .wasm plugins. Plugins can just be dropped into place.

The main win is tighter integration, direct control over compilation caching, instance pooling, and per-request cloning without crossing an FFI boundary to a separate runtime. Plugins are compiled once at startup and cached on disk. Each HTTP request gets its own cloned plugin instances, no recompilation, no FFI overhead, full thread safety.

There are other advantages I haven't implemented yet, for example it's possible to run wasm plugins async, using the same async task manager I created for https://github.com/johanjanssens/frankenasync without taking up threads.

[johnzfitch]

@johanjanssens You changed the future. This is big, seriously.

And how poetic.. PHP just quietly winning in the background all of these years. All thanks to clever developers like you who have kept pushing the boundaries of a language that the popular crowd grew tired of talking about a many years ago. I’m genuinely excited about this and can’t wait to start building on it.

If you're ever in the Bay Area (SF) please let me know, I'd love to buy you dinner or a drink and discuss the possibilities.

[johanjanssens]

Thanks, really appreciate the kind words! Honestly, I didn't do much more than connect a few dots. All the hard work was already done by the people behind FrankenPHP, Extism, Wazero, and static-php.dev. Especially static-php is the real hero here, without @crazywhalecc and @henderkes work none of this would been possible.

That said, I do think the timing is right. WASM is maturing, and PHP is uniquely positioned to benefit from it thanks to FrankenPHP's architecture. Exciting times ahead.

If I'm ever in the Bay Area, I'll definitely take you up on that!