PHP could fade away in the next decade
A pessimistic opinion with a tank full of gasoline
Since Wordpress, Drupal, CakePHP, Laravel, Symfony and many others came into play for web applications, showing how easy was to create a one, it seemed like the language had some kind of second renaissance. Web hosting started to spread like wildfire with a PHP + MySQL + Apache stack and suddenly every had its own site up in ten minutes or so: blogs, shopping carts, photo galleries, you name it.
The guys behind PHP took their sweet time to make the language better, but ultimately they did: old slow versions are now actively deprecated, performance in PHP 7 is better than ever, it got some new features, and even a JIT engine is on track for PHP 8.
After that, I think it will fade slowly to complete obsolescence, leaving the path free for others to take. The only major feature announced for PHP 8 is the JIT engine, which may increase performance in CPU-bound scenarios, but that’s it, the rest are like small bits that won’t add nothing to your existing or next application.
Performance won’t be its killer, but it’s lack of features.
One beautiful goal but losing 4-1
Ruby, Python, Node.JS, and Go, started to gain traction when PHP 5 exposed its problems: slow, dependency messy, featureless. Go came out a bit later, but anyway, look what you could do with these languages:
- Websockets
- Non-blocking IO
- Promises (aka “do this while I’m doing something else”)
- Better data streaming
- Native Server implementation
- Usage for desktop/mobile applications
- Cleaner configuration (have you seen php.ini?)
- Package management (which was later fixed by Composer)
Of these these new features, apart from the Composer, none has been included to the core of PHP, not even announced or planned altogether. Basically, they left the community decide whether to work their ass off to include any of them from the ground up or give it up.
You may say these features are not a necessity for every project, and their availability will depend on a case by case scenario, which is true, but to implement the above features you must decide for a non-official package, or build your own.
Let’s take a look on WebSockets, for example. You must decide between Ratchet, Swoole, Amp and React. That means, for using mission-critical features, you are bound to the documentation and maintainability of the developers behind these packages, while keeping an eye on PHP version updates so they don’t break anything. I can imagine that, when PHP 8 comes, it will take many weeks or months for these to become stable on the new version.
The case of Swoole is discussable. Developers may be not too keen to use software with chinese ties in these times, specially considering the language barrier, but the code is open source if you want to check out.
While there has been a focus lately to add some helpers and order to the language itself, the helper methods mess is something that hasn’t been addressed in years: ucfirst(), strtolower(), str_replace()… Can’t we agree on use a cohesive naming conventions? And why until this day still nobody can extract some keys from an array?
Back to the point, don’t get me wrong about using third-party packages but I expect more maintainability from the folks responsible of PHP itself than a random company.
And don’t get me started on using desktop or mobile applications. PHP is a web-focused language, which is something most developers assume, but even Node.JS kicked out of the park any hopes to make PHP somewhat close to be an alternative in these ecosystems.
In the particular case of Node.JS, there may be high chances to reuse part of your server code modules already written in JavaScript into your mobile or desktop application. For the company owner, this means the company doesn’t have to hire another developer with experience in another language to reach another platform, unless the benefits overweight the costs.
I’m afraid this is what we’re getting at:
- An application will start with a PHP codebase.
- New features will be demanded by the management.
- X language will fill the features PHP doesn’t provide.
- You will end up using two ecosystems instead of just one.
Again, every language has its own perks and caveats, but I always felt that a language should enable you to do things, instead of thinking you got the short end of the stick. If it weren’t for the goodwill of the PHP community itself, the latter would be difficult to assume.
The future is grim
The fact is, by the time PHP 8 comes, it will be with a JIT compiler, but without some of the core developers behind PHP. And with Rogue Weave prioritizing Zend Server instead of keep pushing the development of the core of PHP, the Zend Engine, features like this will be likely never be implemented, and by the time these are considered, Node.js and Go, among other languages, will have already matured with a bigger ecosystem.
As far as I understand, the JIT compiler should allow creating extensions using plain PHP instead of C++, but with low performance penalty, which could accelerate extending the language capabilities from what it’s offered today, but again, the backing and/or maintainability from the creators it what is needed to keep the language relevant, otherwise who knows if the package maintainer goes AWOL like it happened with Predis.
Summing up, the lack of features will make PHP fade slowly from relevance, while the rest keeps leaping forward.
Merry Crisis and a Happy New Fear
