Why Loxodon

PHP runs a large part of the web, and the places code can run have changed under it. Edge runtimes, serverless platforms and browsers run JavaScript. Loxodon brings PHP applications to those places by compiling them, not by shipping an interpreter.

The honest comparison

The existing way to run PHP in JavaScript environments is php-wasm: the Zend interpreter compiled to WebAssembly. It is compatible by construction, because it is PHP. Loxodon has to earn its place on two things php-wasm cannot do.

  • CPU performance. Compiled PHP functions are JavaScript functions, so V8’s optimizing JIT compiles them directly. An interpreter inside Wasm cannot be JIT-compiled by the engine underneath it.
  • Size. A library compiles to tens of kilobytes. There is no multi-megabyte interpreter to download before the first line of your code runs.

What Loxodon concedes: an interpreter will always be more compatible for code that generates code at run time. Loxodon answers that with an interpreter of its own for those paths, and compiles everything else.

What it is for

The first target is WordPress on Cloudflare Durable Objects: one object per site, its synchronous SQLite as the database, requests served with PHP-FPM semantics, and nothing running when nobody visits. Laravel came first in development because modern code is where a compiler proves it is fast.

What it is not

Not a new language, not a PHP dialect, not a transpiler that needs your code rewritten. Current PHP, current WordPress, current Laravel. Where behavior deviates from PHP, the deviation is documented, tested and listed.