| HN Mirror

PHP is, at its core (i.e. after in-engine precompilation), a hand-coded-in-C virtual machine with its ISA purpose-designed for efficiently generating dynamic HTML from the results of backend network service requests.

Honestly, that’s not a bad idea. It’s a lot like how many old game consoles have ISAs that specifically make game software efficient to run compared to generic application software. Purpose-built architectures can be exploited to achieve incredible efficiencies in CPU/memory usage for a given effect—as any demoscene programmer could tell you. Even emulators running this CISC code often outperform the same code written idiomatically for the host arch (see: one of the reasons that z/OS FORTRAN programs stick around.)

So far as I know, we haven’t recapitulated this approach in any other modern stack. Sure, we “compile” templates, but only to the bytecode ISA of the scripting language hosting the MVC framework, which has none of these dynamic-HTML-oriented CISC opcodes (other than maybe the Erlang VM’s vectorized write of “IO lists” using writev(2).)

A web MVC framework for another language (e.g. Ruby, Node, Elixir, whichever!) would actually likely do well in performance terms by having its “view” component be a static PHP (or Zend microcode) generator, feeding the web frontend (e.g. Nginx) a directory of PHP to expose to the world, which would only call into the server backend (and so the MVC controller) through API-subdomain subrequests. The static-generated PHP “app” would serve the same purpose as a JavaScript SPA... but would exist on the server together with the backend, so there’d be much less point in persisting state there (since you’re not patching over a latency boundary by doing so.)

There’d probably be even more efficiencies to uncover if you designed an ISA from the ground up to be used solely for this purpose (i.e. being “edge-worker logic” spat out during a backend’s compilation phase), though, compared to PHP which must be Turing-complete for those that want to use it as a full-stack solution. I imagine the resulting ISA would look like some weird bytecode hybrid of eBPF, Server-Side Includes, and Nginx’s in-memory representation of loaded location{} entries. (I also imagine that some Cloudflare engineer already has a design for such an ISA in a notebook somewhere, as a more-efficient-through-constraints Cloudflare Workers target—but they haven’t bothered going further because it’s kind of an arcane idea and they’d need buy-in from framework devs before it’d be useful to build.)