I don't know how strict JavaScript garbage collection rules are. This was non-observable for the longest time but FinalizationRegistry now exists which makes cleanup observable. It sounds like basically no guarantees are provided when an object will be cleaned up, so presumably an implementation would be allowed to make optimizations such are proposed where for PHP.
function foo() {
return function() { };
}
console.log(foo() === foo()); // This must log `false` in a compliant implementationBut, since when has PHP ever prioritized correctness or consistency over trivial convenience? (I know it's anti-cool these days to hate on PHP, but I work with PHP all the time and it's still a terrible language even in 2026)
> Stateless closures, i.e. those that are static, don't capture any variables and don't declare any static variables, are cached between uses.
PHP has a vastly simpler toolchain (making it much more effective for rapid iteration), much more consistent and well-thought-out syntax, a more extensive standard library, type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to still have interpreted code at the end), native and full-featured object orientation, generally better runtime performance, and a package ecosystem with Composer that isn't overrun with inane vanity projects and supply-chain vulnerabilities.
The only major downside to PHP is that it's not great at multithreading, but if you're building microservices where parallelization is handled by an external orchestrator, then you can design around that pretty effectively.
All major server-side JS runtimes are capable of executing TypeScript without transpilation these days. Complex build processes are only really a thing for client-side JS. The normal state of affairs these days is to run server-side code with no build step whatsoever.
On the other hand, Javascript's parallelization is one of the hardest-to-understand things I've ever seen: in order to really grasp the async/await model, you have to know the whole story of callback hell and how modern Javascript papers over it while carefully preserving backwards compatibility.
> PHP has a vastly simpler toolchain
Firmly disagree.
You can install Node and have a basic server running in a few seconds.
PHP requires installing and setting up a server tied into FPM and then reconfiguring a slurry of bad defaults. If you don't avoid the footgun of "traditional" deployments, you get to deal with mixed versions of source. If you don't avoid the footgun of "native" sessions, you get to deal with INCOMPLETE_CLASS errors galore.
And if you want a dynamic frontend, you're still going to want to bust out JS.
> I can't find any reason why I wouldn't use PHP instead
Using a single language for both frontend and backend with (largely) the same availability of tooling and the ability to share code (i.e. type definitions).
> generally better runtime performance
I find this hard to believe? Intuitively, I would assume that the Node / Bun engines are significantly faster than PHP - which doesn't even come with it's JIT enabled by default on the (perfectly valid) note that backends are almost always constrained by DB times.
> a package ecosystem with Composer that isn't overrun with inane vanity projects and supply-chain vulnerabilities.
Functionally, Composer is worse than any of the NPM package managers IMO. PHP's global, shared namespaces preventing monkey patching and nested dependencies is a huge burden when you need to use Lib A and Lib B, but both have conflicting dependencies on Lib C.
But the only reason it doesn't suffer (as many) supply chain issues is two-fold:
1. Packagist's source of truth is the repo and tags. It's much easier to notice a Github account being compromised, which is already harder because it's always had better account security expectations, than NPM. But this comes at costs - such as being unable to rename a package in-place, because Composer gets really confused when it clones a trunk that has a different name than what you asked for. And it's not intrinsically more secure, since tags are not immutable and people can host on less secure VCS platforms.
2. But more than that... it's just less used? The PHP ecosystem is noticeably smaller and has way less happening.
So its very much trade-offs.
- Batteries included, everything you need out of the box. No need to npm install left-pad
- Optional, per-file strict types, without the need to transpile from another language
- No need to build anything, lightning fast scripting language
- Is its own HTML templating language (or XML), no need for JSX
- No supply-chain fiascos, stable and mature ecosystem