Posted on: 2026-08-16
I don't hate PHP by itself. I just hate what some people have turned it into. PHP itself is fine. I use PHP a lot, in fact this blog is written in PHP. I wrote most of our server automation scripts in PHP.
The odd thing about that the language is, that it's not just a multi-paradigm language but also that it has multiple personalities. There's old PHP and new PHP. I mostly work within the realm of "old" PHP, as this is what I learned when old PHP was the only PHP. Concepts from "new" PHP often look foreign, odd and inefficient to me. In my opinion "new" PHP introduces a lot of stuff for which the language simply wasn't made. Besides, there are often existing, better alternatives to PHP if you actually need those things.
But why even is PHP everywhere? And what are the actual problems of modern PHP, except that it looks "weird" to me? To figure this out, we have to have a bit of a history lesson.
The old PHP
By old I mean the time in the early 2000s when PHP 4 was still around but slowly replaced by PHP 5. Occasionally you'd see PHP 3.
Back then PHP stood for Personal HomePage. Most Websites were static HTML files, but occasionally you wanted to run some code on the server as well. PHP fits this nicely as you can just put in your whole page with some code intermixed. A syntactically correct HTML file is also a syntactically correct PHP file - with no server side code. PHP can be used as a templating language, to have the header, footer and menu in separate files which could be included in the main content and not have to be copied over and over. Basically a replacement for Server Side Includes (SSI). Or one could implement a guest book or visitor counter which were quite popular back then. But for the latter two options you need some way to store data on the server, for example a plain text file or a MySQL database.
Soon web content itself moved from PHP files to the database. More pieces of PHP got written to edit those database records and thus the first Content Management Systems (CMS) were born. Now people could edit their own websites without ever touching PHP and HTML code themself.
This is all good, and other languages can do that too. But why is PHP so prevalent? The answer is that it's incredibly easy to set up. This is true both for developers as well as hosting providers. PHP has no application server which needs to be deployed, managed, restarted or anything. You just plop a PHP file on a Webserver and open its URL from the browser. Found a bug? Edit the file, press F5 in the browser. That's it. I can hardly imagine a lower barrier of entry. Hosting providers can easily segregate multiple customers from each other without fancy containerization or virtualization - both of which were very expensive for a long time. PHP also has some built in security measures to prevent a rogue script from consuming all resources.
Even with "better" languages coming out, sheer inertia has kept PHP still going strong.
Not having an application server also comes with some drawbacks, though. Every request starts fresh, there is no global state. So you can't initialize some data structures on startup and have them around when requests come in. There is no startup. If you need some larger data blocks you have to reload them on every single request. There are some ways around that. You could store data in APC, Valkey (Redis) or Memcached for example. This works, but is less convenient than having it directly available in a variable. Also this only works for data. You can't hold on to code between requests, everything has to be reloaded from disk. And with PHP 5 or below this meant also parsing the PHP file, compiling the abstract syntax tree and then running the code in an interpreter. On every request! And here I complain about new PHP being inefficient ... sheesh...
Well, fact is, you just had to accept this and adapt the code to the language. Common wisdom was to only include code you actually needed. You'd had to be smart about modularization. Also, when it started it was mostly static content with some dynamic stuff sprinkled in. Bandwidths were lower, latencies higher and that little bit of extra CPU time was hardly noticed.
To further ameliorate this, PHP comes with a huge library of functions, written in blazingly fast C. They are doing many things you might need in a web application like: connecting to databases, making HTTP requests, editing pictures, parsing or generating JSON or XML, sending mail, reading mail, calling external programs and even SSHing into remote hosts.
Also while PHP itself is not multithreaded, each request runs in its own thread with the ability to use multiple CPU cores. Unlike Python, for example, where you need multiple application servers and load balancers to utilize more cores.
The new PHP
All the stuff mentioned in the previous chapter still works. A PHP 5 application following best practices will still run on PHP 8. I've written a PHP application about 20 years ago as of today, which still works. I had to do some minor adaptions - which is because I didn't follow best practices. So it's not like Python where there was a major break between versions 2 and 3.
But this is not how you "PHP" nowadays. Usually it involves some sort of Framework like Laravel or a complete CMS like Drupal 10. You get the ball rolling with "composer", which works a lot like npm in the Javascript world. And like npm, everything has a lot of dependencies. So it usually pulls in dozens or hundreds of PHP files, which of course all have to be run on every request.
Among those are completely redundant libraries like Guzzlehttp - PHP can do that by itself, the streams API has all that's needed. Still not enough? Use curl, everyone has it installed. There are more libraries which just wrap around existing PHP functionality to ... I don't know, provide a more object oriented interface? Hello, the 90s called, they want their buzzwords back! PHP doesn't force you to use objects, it works just fine procedurally or functionally too.
Or templating languages like Smarty. Newsflash: PHP is a templating language. Implementing a templating language within another templating language is just plain stupid. (Google "inner platform effect"). It's not even that they are interchange with other platforms. So the whole argument "But, but, .. then the frontend dev has to learn PHP!" doesn't count. That bit is easy to learn and at least PHP knowledge is expandable. Knowledge in your stupid, limited, PHP-only templating language of the month, is not.
More concepts from Node.JS and Java also moved in, like most frameworks now come with their own Router where you set up paths to the various bits of your program. Or Object Relational Mappers (ORM) which introduce another indirection to the database.
So in a "modern" application upon startup, the database gets connected, ORM configured, classes instantiated, Routes laid, all normal stuff which you might also find in a Node or Java app. But in those languages, after all the setup you are ready to serve all the requests that come in. This makes sense - trade some extra time on startup for quick response times. In modern PHP however, you do all that, run thousands of lines of initialization code, execute one single request - and then throw it all away. At the next request all this starts again!
Ah, here I start to get really angry. It's just so wasteful. But of course the PHP interpreters development didn't stand still. Nowadays with extensions like OpCache, code is only parsed once and doesn't have to be read from disk on every request. The code execution engine also constantly improved. On the same system, PHP 8 is more than four times faster in executing code than PHP 5. Also CPU speeds improved significantly.
But does this mean we should just write inefficient code because it runs fast enough anyway? No! Inefficient code leads to more wasted time, frustration, more wasted energy, increased use in computing resources and CO2 emissions.
This architecture has another major drawback: There is no way to use websockets. You could theoretically do long polling if you're desperate, but this leads to very high server load and your hosting provider will hate you. Also you will figure out that by default, PHP sessions are blocking, leading to nasty surprises.
Long running or scheduled tasks have to be managed by some job scheduler and cronjobs have to be set up externally.
Can we make it better?
Yes. There are frameworks like ReactPHP which allow PHP to be a non blocking application server like Node.JS. This means instead of being embedded into a webserver, the PHP interpreter becomes the webserver itself. State can be shared between requests, initialization only done once. Websockets become a possibility. It would fix everything wrong with modern PHP! So why aren't we rushing towards it?
First, many libraries can't work in a non-blocking fashion. This was never needed in PHP, unlike Node.JS where this was a key concept right from the start.
and ... did you realize what this also means? It means "application server". Something that has to be supported by the Hoster. something that has to be started and stopped. Luckily, thanks to virtualisation, Docker and serverless architectures, this isn't really an issue anymore. There are many options to host your application, no matter which requirements it has.
But also ... at this point there is really no more advantage to PHP. You have limited reuse of existing code, bad library support and now even the multithreading is now lost. You might as well just use Node.JS, get the same software architecture, more library support and a language you probably need for the frontend anyway.
Conclusion
Is PHP a bad language? No.
Plain PHP is perfectly fine. Even WordPress is ok-ish of you don't overdo it with the plugins. But in my opinion, frameworks like Laravel, Cakephp and Drupal 8 and above are extremely overloaded, inefficient and should be avoided. Even if you "only" think about using Doctrine, maybe consider switching to a language which is actually made for architectures like this.
If you plan using plain PHP, check core language features first before venturing to composer. if you need composer, carefully check your dependencies so that if you only want a spoon, you don't get the whole cutlery box, the drawer, kitchen, the whole apartment, building and city block pulled in as dependencies as well. Basically just like Node.JS with NPM, except that you'll feel the penalty way more in PHP.
And then go ahead! Use the newest PHP, take advantage of new language features making live easier - no need to need to be anachronistic about anything. PHP 8 is great!
Just stay away from inefficient frameworks.