Two years from PHP “dying”: There are other tools
Your job is to pick the right tool for the right job
Some time ago I wrote not once, but twice, my thoughts about PHP “dying”. The first article evidenced that PHP was not going to die from one day to the other — as it powers pretty much all the Internet — but it would be a slow process, mainly fueled by the lack of competitive features.
The second article explored more about the “dying” concept for a programming language. These do not die, but they just become obsolete, replaced by new paradigms of, what we could consider, the successor languages. Yeah, there are still old COBOL programmers around, but no new projects are made with COBOL in mind.
This article goes beyond the dying concept. Why someone wouldn’t use PHP when there are some vogue programming languages that have gained notoriety these last years?
It’s only PHP anymore
First few minutes of Programming 101, introductory speaking for the adventurers who think they’re the next Bill Gates, Elon Musk or George Hotz: it’s not about the language, but the right tool for the right job.
PHP is, indeed, a great and mature tool for Web Development. There are excellent frameworks going around like Symfony, Laravel, CodeIgniter, and even Laminas (ex-Zend Framework). There are also entire ecosystems that not only are built around PHP, but also fixes some problems the language had (and still has) since it’s inception, like Revolt, Open Swoole and Roadrunner.
Every language is prone to headaches when they’re out of their comfort zone. You can say PHP itself is a good language to make web sites, and only fools will argue. Now put PHP on a CLI and it’s not that awesome anymore. Put PHP to deal with networking, multithreading, binary data handling, and everything that is far from an HTTP Request, and you will see the cracks appearing. PHP can work in this scenarios, but becomes less convenient and very opaque.
Making statements like “PHP is dead” because of these cracks is very naïve. It’s like trashing a Lamborghini off-road because it can’t make 0–100mph in 10 seconds over rocks, and rant on Twitter. That’s nuts, but there is people who also are antivaxers, so there is that.
PHP doesn’t do everything. Nothing does.
After investigating in 2020 some programming languages that are still hot today, I couldn’t fathom the idea of using one language for everything; even if its preferred for many companies to have one single stack its borderline impossible. You can try with Javascript, something that can work frontend to backend, but that is just wishful thinking.
Let’s go into the rabbit hole. As you may be aware by now, PHP is (still) great to handle the web at its basic core, but still can’t keep with new technologies and a decent performance compared to others languages outside of the web. Until this day, you still need a Web Server to serve to the PHP process, because a Web Server will deal with sockets and networking and process management way more than PHP would do.
The most notorious example of this “can’t keep up” are WebSockets. PHP can handle WebSockets, but not as performant as other languages like Node.js, as there is a lot of invisible overhead.
Because Javascript is accessible and Node.js is relatively performant, there are maintainable implementations that offer some basic functionality for WebSockets, like the ws library.
Now, on the networking side, going deep into socket handling, memory management and micro-optimizations, and you will find yourself far from animals like PHP, Javascript, Python, and similar… but that doesn’t mean animals can’t complement each other.
For example, take soketi. This NPM package simply sweeps the floor with other alternatives that offer Pusher-protocol-compatible WebSockets server. The secret sauce is µSockets, its networking foundation. Dubious events aside, this is a software written in C++, but compiled to become a Node.js core library that exposes itself on the surface as a Javascript object.
That’s not an example about “Node.js is better”. It’s about the simple realization that you can’t beat a low-level programming language with a high-level one. A high level language exchanges convenience for overhead and opaqueness, while a low level one exchanges plumbing for performance and control.
Of course that, if it remained as a C++ library, nobody would use it for web development, because creating web-pages in C++ is like painting a wall with a toothbrush. The key that makes it so developer friendly is that is ported and exposed to a high level language, which can be used for Web Development. No doubt it could have the same effect if, for example, was ported to PHP as an extension, but I highly doubt it will gain more than already has in the Node.js community.
The grass is greener at the other side
Let’s get back a little and take hard turn. The boss asked for something more surgical, like a like a tool that streams video without having to consume 128MB per stream, which in turn will lower the server bills.
When you have to focus heavily on networking, memory, filesystems, and even databases at some extent, which I consider The Four Horsemen of Apocalypse, that’s when high-level languages take a seat in back. From the primitive C, passing through the ageless C++, to the recent wanna-be-successors like Rust and Go.
The problem with these tools are the jobs they can do in a reliable way. There is no harm in trying to make a web page with Rust or Go, there are even frameworks for that, but you should consider that they’re way behind the convenience that other languages offer. As someone said to me while watching an F1 race, “there is a reason why the driver didn’t engineer the car, which is the same why the engineer didn’t drive the car”.
For the case of Rust, which seems more low level and comparable to C++, it’s a great programming language that’s gaining traction for every day that passes, and probably its breakthrough will be when it becomes acceptable for the Linux Kernel. Who knows if in the future Node.js and PHP exchange their C core with with modern Rust.
Go, on the other hand, seems like it sits as a copilot. It doesn’t deals with memory management as it has its own Garbage Collector, and offers a lot of convenience over cooperative multithreading without extreme overhead, which is something very difficult to take advantage of — may be why single-thread high-level programming languages are so attractive to any developer. There is excessive plumbing here and there for the purpose of control, but its still an excellent tool to build specific multi-tasking software that needs to scale. That’s why Go was made for.
For example, I could make a web page where an user receives a “ticket” to be able to stream video just using PHP and MySQL. A Go server would check the ticket and stream chunks of video files that would be already transcoded by a Rust transcoder in the background. Trying to do that on PHP? No dice. On Go? Would take years. On Rust? Would take decades.
Won’t die soon, unless a big f*ck up
Is PHP dying? On the web it won’t, and as long as the PHP Foundation have working brains, it may have a long life until the next big thing arrives (who said VR instead of web pages?). We can thank mostly to PHP 7 and PHP 8 that the language didn’t become a resource hog like Adobe Flash, otherwise everyone would have been using Node.JS by now.
Of course PHP has no space on anything that’s non-web, and tools like Rust, Go, Node.js and Python have ensured it won’t take their job anytime soon. Rest assured, nobody in their minds will try to make a web page using the aforementioned alternatives unless they have an specific set of features that PHP doesn’t offer. Even on that scenario, it’s better to look for a complement to a PHP project that ditching PHP altogether.
I learned the hard way that, as of today, there is no “do-it-all-well” language. It pays much better to pick the right tool for the job, than using one tool for all the jobs, even if you’re a little inexperienced with the others. In the process, you may learn what you were missing out.
You can hammer a nail into a piece of wood with a screwdriver, but surely you will want to use a hammer and do it using less than half of the time and effort. Nobody thinks that using screwdriver is “dead” because of that.
If you think that’s insane, try to drive a screw with a hammer.
