PHP's performance can be significantly lower than JS, because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request. Now there are a whole bunch of tricks both in the language and with tooling to alleviate that, but still it's inherently there. It's an advantage for other reasons though.

> PHP's performance can be significantly lower than JS, because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request.

Sure, in PHP, the reality is that after your request is processed, all the state is garbage and is thrown out. But once you embrace that reality and stop trying to make sculpture from garbage, you can make some pretty damn fast pages that get straight to the point. Of course, a lot of people look at my fast PHP and say that it too is garbage, but at least it's fast garbage :P

There are advantages to the lack of application state, though. Memory leaks and similar bugs became largely irrelevant, for instance. Regarding performance, a simple LAMP stack on a dedicated machine can easily give you <250ms pageloads for many web apps. If that's not fast enough, or you're averaging dozens or hundreds of requests per second, you're probably big enough that you can use parallelization or more exotic architectures to speed things up.

I agree that PHP's request oriented "shared nothing" approach has its advantages.

That being said there are very decent options for long running processes/application servers these days - see RoadRunner, Swoole and Frankenphp.

> because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request.

Where "application" is basically a single page with less code than a typical React page. Even 20 years ago you'd run into DB struggling to give you data fast enough before you hit any issues with the "re-running the entire app".

And you have to screw your database really badly to see any issues early. Hell, phpBB was horrendously bad, running dozens of heavy DB queries on each page, and was still powering some of the internet's busiest forums.

> Now there are a whole bunch of tricks both in the language and with tooling to alleviate that, but still it's inherently there. It's an advantage for other reasons though.

Yes. It is an enormous advantage: it's fire and forget. You don't need to "SSR" your app (getting all data and state), ship it to the client with a bundle, then "re-hydrate" it (once again pulling data and state from the server) etc.