> "If node is so fast why does my PHP site feel way faster than this React+Redux+Node thingy? An inquiry into what 'fast' means."

this actually a true statement.

I probably spent a thousand hours deeply mocking PHP, but everytime I use their website I'm shocked how lean everything is.

Given the infinte amount of brilliant work done on js VMs and HTTP2 or whatever, I think there's something to be learned there.

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.)

I could argue that all 3 are true statements.

"But is it web scale?"

"How to Use Apache and Postgres to Serve a High Traffic Website on a 1U Server and Use the Leftover Resources to Host an NFS Server with All Your Pirated Music On It"

If it can handle 100k billion connections simultaneously I will never need, I am sold!