We build in both, so we have no side to defend. What follows is how the decision actually gets made on a real project.
Where each one is genuinely stronger
PHP wins on deployment. It runs on essentially every shared host, needs no process manager, and a file dropped on the server is live. For a content site, a brochure with a CMS, an admin panel, or anything that must run on cPanel hosting the client already pays for, that is a decisive advantage.
Modern PHP is also not what its reputation suggests. Typed properties, enums, attributes, real performance gains in 8.x. Laravel is a genuinely good framework.
Node.js wins where connections stay open or work is I/O-heavy: real-time dashboards, chat, streaming, anything with websockets, and anything sharing code with a React or Next.js front end. One language across the stack is a real productivity gain for a small team.
It also wins when you need a library that only exists in the JavaScript ecosystem — which, for anything involving modern front-end tooling, is often.
Where hosting decides it for you
This is the part that gets skipped, and it is frequently the whole answer.
Shared cPanel hosting runs PHP natively. It can run Node through the Node.js Selector, but the app needs a persistent process, which means it can be restarted by the host, is harder to debug, and consumes memory continuously rather than per-request.
If the budget is a £5/month shared plan, PHP is not a preference, it is a constraint. If there is a VPS with a process manager, both are open.
We have talked clients out of a Node rewrite purely on this: the app would have run fine, but the hosting they wanted to keep could not supervise it reliably.
Where the team decides it
The more important question is who maintains this in two years.
An in-house team that writes JavaScript should get Node, even where PHP would be marginally simpler, because they can actually change it. A client whose only technical contact is a WordPress-familiar contractor should get PHP for exactly the same reason.
A stack nobody in the building can edit is a liability regardless of technical merit.
What we would not do
Rewrite something that works because the stack is unfashionable. Rewrites eat budget and reintroduce bugs that were fixed years ago.
Split for the sake of it. A separate API and front end doubles the deployment surface. Worth it at scale, overhead at small scale.
Chase benchmarks. Almost no site we are asked to build is CPU-bound. It is bound by database queries, third-party calls and image weight — which are stack-agnostic.
A reasonable default
If it is a website with content and an admin panel, on shared hosting, maintained by non-specialists: PHP, no framework or a light one.
If it is an application with live data, shared front-end code, or a real-time element, and there is a VPS: Node.
If it is both — a marketing site plus a dashboard — build them separately and let each use what suits. They only need to agree on the database and the API contract.
