I have been in the web-tech industry (is that even a thing?) for the past 25+ years and what always surprised me was the hate PHP as a programming language received early on, while at the same time gaining a lot of popularity world-wide.
The hate usually stems from its massive “non-enterprise standards” that have caused years of insecure software, messy code bases and also questionable software designs: remember the times when we would send emails during sign-up in-sync and thus the whole HTTP request would be blocking or even failing depending on the SMTP server? ¯\_(ツ)_/¯
However, at the same time, the popularity came from exactly that: being “non-enterprise”. This created an extremely low entry point for creating a server-side-rendered websites that could use a database as backend. Other languages were still catching up to this new thing called “the interwebs”. You did not need a CS degree to whip out something over a weekend and most likely that was also why Facebook was written in PHP. It was essentially our “vibecoding” equivalent back in the day. Even today it is also extremely cheap to run on shared web-hosting providers – no containers or VPS required.
PHP kept its momentum in popularity throughout the years due to three distinctive “renaissance”-events which also helped moving it into more online/web-based businesses:
- Introduction of composer as package manager. Previously the community was split between PHPClasses.org, PEAR and random .zip files on homepages (as GitHub did not exist or was not popular enough in the early days). Packagist.org created a exponentially growing ecosystem of high quality libraries for various problems.
- The formation of PHP-FIG/PSR. Created a good foundation and understanding across all developers, standardizing PHP code.
- The rise in popularity of Laravel making it the de-facto choice of framework within PHP. It is not that PHP frameworks did not exist previously, but Laravel was the only framework that simplified the implementation of business logic and being extremely developer friendly.
Bonus: the relentless release cycle of PHP compared to its peers. Listening to the community on changes, improving performance year-on-year and locking down on security (Suhosin is deprecated these days).
All of this was not enough though and thus the “PHP is dead”-meme still lives today as our yearly mecca:
So why do I think PHP is going to die?
Let us be real. Even if PHP is not dead yet, it has lost a lot of its popularity already. Sure Mediawiki and WordPress are still carrying the torch, but I hardly see any companies anymore investing in it. But thats not even my point.
I think what made PHP a popular choice was the ability to essentially create a simple project over a weekend – and if you used Laravel, it would come with lots of bells and whistles out-of-the-box. At the same time you knew its limitations: performance and not the best code.
But what if you had the freedom to develop in any language and equally only take a weekend to create web-based project that has 10x the complexity, would you still chose PHP? With Codex or Claude you remove any personal constraints or limitations of being “stuck” with $language. But also what ever pulled you into writing PHP syntax is gone, as you are now distant from the AI output itself.
That is something we precisely did at DigitalTolk where we are slowly replacing smaller services written in Laravel to Go, reducing costs by 60% while additionally increasing performance for our customers. You can read more about it on my LinkedIn post:
Need a single distributable binary? No problem with Go/Rust/C(++) using Claude. Need to work with LLM? Sure Claude can do Python.
The advantages that made PHP still relevant are diminishing quickly. Why would the next generation of software engineers learn PHP? What edge does PHP still have compared to other languages?
The “4th renaissance”?
I am no PHP hater and either way, all of this is only my opinion. So I will bring some suggestions to the table that I think could push PHP back into a competitive direction by making it more cloud native and improving its base-line:
- PHP needs to get rid of having Nginx/FastCGI as a requirement. Let PHP-FPM speak HTTP directly. If you want to terminate TLS via Nginx, it becomes a choice, not a requirement.
- Make it a compiled language with virtual machine similar to Java. The times of recursively creating PHP-files to serve PHP-files are dated (*cough Smarty). Compilation with checks and strict typing will increase the code quality fundamentally.
- Laravel, please do not make me run three processes: webapp, queue, cron. At least reduce it to just webapp, worker. No supervisord tricks. Natively.
- WordPress, please make yourself cloud native by default. People have been looking for alternatives for years because its painful to scale, but it does not have to be. Lead by example, others will follow.
tl;dr
Is PHP dead? Not yet. Will PHP ever die? Likely if nothing changes – anyone still remembers Perl 🥲? Vibecoding has not only done a massive switch in the software/tech industry, but also changed the next generation of software engineers. Why learn PHP if you can get better results and better agility with any other language while vibecoding?
And the reality is most likely somewhere else: not only will PHP die, most likely many languages will seize in popularity due to AI.
7 responses to “PHP is Dead (and AI is to blame)”
Actually:
* PHP needs to get rid of having Nginx/FastCGI as a requirement: that would be FrankenPHP, open source and supported by the PHP Foundation
* Make it a compiled language with virtual machine similar to Java: the ecosystem provides many ways to achieve performance, opcache and preloading are already enough for your requirement (along with cache for smarty or similar). Also, if you have very specific needs in terms of performance, FFI allows you to code in another language for a very specific task.
* Laravel, please do not make me run three processes: webapp, queue, cron: as far as I know, they do not force you. You can do command only, http only, workers… It really depends on your use case rather than your framework.
* WordPress, please make yourself cloud native by default: this one I must agree with! Though it probably doesn’t really target us, the idea is to allow non developers and non tech to power a website easily. The “software engineer” way is definitely to add a storage plugin and disable anything auto (updates and all), most mutable features and all, and just rebuild in your CI. I’ve done it before, it’s not hard at all.
@Thomas D:
1) What is the advantage of PHP-FPM speaking FastCGI instead of HTTP?
2) Correct, so the only thing missing is a CLI command to pregenerate opcache files so its not reliant on code paths to be executed while also allowing the opcache optimization to be part of the deployment asset.
3) WP does target us because it lays the foundation for new comers due to its popularity. phpBB did something similar back in the days by adopting composer – leading by example. Even alone making wp-uploads cloud-native (local-fs could still be a driver option) by default changes the perspective of how plugin/theme developers think about their implementation.
Or a rating system per plugin based on best practices.
you will be dead in max next 50 years but PHP will be there.
This comment landed in spam, but I had to approve due to its hilarious absurdity of a statement. But also why hide behind anonymity?
I believe swoole and symfony swoole-bundle allow everything that you mention 😉 https://github.com/symfony-swoole/swoole-bundle/blob/develop/docs/swoole-task-worker-commands.md
It’s going to be really hard for PHP developers to digest, but sadly, this is the reality.
If we look at pre-built frameworks such as Laravel, they rely on relatively heavy bootstrapping, which takes time on every request. On the other hand, by leveraging AI, we can more easily build smaller, purpose-specific components of our architecture—such as authentication, notifications, queue workers, or algorithms that require intensive arithmetic operations—in Go.
Go compiles to a standalone binary and is particularly well-suited for long-running services and highly concurrent workloads. PHP/Laravel traditionally relies on PHP-FPM workers, where each worker consumes memory and handles a limited number of requests at a time. Depending on the application, a Laravel/PHP-FPM worker can easily consume tens or even hundreds of MB of memory. Handling higher concurrency can therefore mean running many workers and allocating significantly more memory.
A Go service, on the other hand, can handle thousands of concurrent operations within a single process using lightweight goroutines. For certain workloads, something that might require several GB of memory across PHP workers could potentially run within hundreds of MB in Go. That can translate directly into fewer containers, smaller instances, and lower infrastructure costs.
And this is an important point: it’s not always about the code. Architecture decisions also come down to infrastructure, scalability, operational complexity, and ultimately cost. If a service can handle the same workload with 1 vCPU and 512 MB of RAM instead of requiring multiple PHP workers consuming several GB of memory, that difference becomes significant when you’re running dozens or hundreds of services at scale.
Previously, we were somewhat limited because we mainly used Laravel, as that was what we were most comfortable with. Now, with AI, the barrier to working with other languages and ecosystems is much lower. We can step outside that comfort zone, use technologies such as Go where they make architectural and economic sense, and ultimately deliver more.
I’m still a strong supporter of Laravel because it gives you an excellent starter pack for building enterprise-level applications. You get routing, authentication, queues, events, ORM, migrations, validation, notifications, and an enormous ecosystem out of the box.
So the point isn’t Go vs. Laravel or replacing PHP everywhere. It’s about using the right technology for the right part of the architecture. Laravel can remain the backbone of an application while Go handles specific workloads where concurrency, performance, memory efficiency, or infrastructure cost justify it.
With AI making it easier than ever to work across different technology stacks, being comfortable with one framework should no longer be the reason we don’t explore a better tool for a particular problem.
1.Qbix may replace nginx/php-fpm.
2.There is a new feature-rich PHP ecosystem available now that is faster than Yii 2 basic (macropay-solutions). Besides being fast in PHP-FPM share-nothing, it is also made to be run on Qbix CoW Fork-per-request mode out of the box. It also features out-of-the-box CRUFD (f = filter) built-in capabilities.
3.Compiled PHP, just like PHP-True-Async, will result in Frankenstein new versions of PHP. There are already people working on them.
4.PHP will die only when the projects and the devs maintaining them die.