Why PHP is obsolete

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

I was a huge fan of PHP back in the year 2000. I started using it right before the official release of 4.0 in April of that year. At that time, if you wanted to build a website, the main alternatives were C, Java, Perl and ASP. My criticism of those 4 were:

1.) C — too complicated for a fast changing website. Compiling an app took time, compiling was slower back then, there were fewer Open Source tools, and proprietary tools were outside of my budget. Too verbose. Managing dependencies was a very complicated situation.

2.) Java — better than C, but still too verbose, and compiling took time, which made development slow when you were dealing with a rapidly evolving website. Managing dependencies was a very complicated situation.

3.) Perl — as good as PHP in most ways, except that it lack any kind of package manager. There were modules in CPAN that could do almost anything, but you had to download and install them. Managing dependencies was a very complicated situation.

4.) ASP — as good as PHP is most ways, except it was a Microsoft tool, and using it would have sucked me into the expensive world of Microsoft.

For 3 of these, I’ve written “Managing dependencies was a very complicated situation”. That was probably the key thing about PHP, at least for me. It had an all-in-one philosophy. At that time, there was nothing like modern package managers. Nowadays we are spoiled with awesome tools like Bundler for Ruby and (my favorite) Leiningen for Clojure. But there was none of that in 2000. “Package managers” at that time would have been a reference to Linux distros, which sort of introduced the idea. And even the Linux package managers have gotten better since 2000. PHP’s all-in-one philosophy solved the package management problem that existed at that time. But now that we have a wealth of great package managing tools, PHP’s greatest strength is rendered obsolete.

PHP had other strengths, of course. It was optimized for the web, but that hardly makes it unique nowadays. For those of us who were frightened of C, it gave us nice wrappers around C functions. But other languages make this even easier nowadays:

Julia’s only drawback at this point is the relative dearth of libraries — but the language makes it unusually easy to interface with existing C libraries. Unlike with native interfaces in other languages, you can call C code without writing a single line of C, and so I anticipate that Julia’s libraries will catch up quickly. From personal experience, I was able to access 5K lines of C code using about 150 lines of Julia — and no extra glue code in C.

These last few years I was hired by several corporations (Wine Spectator, Timeout) to work with their systems, most of which was PHP, and most using the Symfony framework. I have already written my criticisms of some the systems that I had to work with. I feel that the people who nowadays use PHP in corporate environments have forgotten why PHP first appealed to anyone. I can tell you what advantages PHP offered in 2000, but what does it offer today? It is slow, it is cumbersome, the systems have become very complex, the uncompiled nature of PHP has become a problem as people try to do more ambitious projects with it. If you build a CMS, and you have traffic that needs 100 webservers, then you need to deploy the whole CMS to each of the 100 webservers.

What is cutting edge in the world of PHP nowadays?

People are adding pthreads yet PHP lacks the tools to manage concurrency (for a point of contrast, check out Clojure).

Complicated code cache systems in Symfony. As in: “Note that there are two disadvantages when using a bootstrap file: the file needs to be regenerated whenever any of the original sources change (i.e. when you update the Symfony2 source or vendor libraries); when debugging, one will need to place break points inside the bootstrap file.”

Annotations added into the comments. Unlike the author, I think they are still a bad idea when added to the PHP language itself. If you need to model cross-cutting concerns, maybe you should switch to a language that handles cross-cutting concerns with grace, rather than use a language that bolts on annotations as a half-baked solution.

A backlog of fixes necessary to deal with a long history of inconsistent development.

Bloated memory management.

Ceremony oriented programming without the benefits of speed or compile-time checking (which are the normal benefits of ceremony). Back in 2000 one of the arguments for PHP was that it allowed us to escape the verbose ceremonies that were common in languages like Java. Do we really want PHP to end up looking like Java?

A love of complexity for the sake of complexity.

No management of configuration settings. This is similar to the lack of package managers that PHP used to suffer, relative to languages such Ruby or Python or Clojure, but here no work has been done to solve to the situation, rather, it is left to sysadmin tools such as Chef and Supervisor to solve the situation.

Invisible demon monkey patchers. Traits are a lot like monkey-patching in Ruby, but traits are even harder to track and debug.

Ambitions that outrun the language. As Fabien Potencier says, PHP has some great features. Which is odd. It’s like having a super-powered Ferrari engine in a rusty old Fiat body.

An endless assortment of convenience functions.

And, of course, there is the famous essay “PHP: a fractal of bad design“.

Where PHP has cool features (as with the Streams and Iterators that Fabien Potencier mentions) they tend to be bolted on to the language, rather than deeply integrated. One never gets the sense that there is any profound philosophy shaping PHP. Rather, we have Ramus Lerdorf saying stuff like:

We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don’t care about this crap at all.

As a point of comparison, Yukihiro Matsumoto describes Ruby this way:

For me the purpose of life is partly to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, So Ruby is designed to make programmers happy. If you get your job done quickly and your job is fun, that’s good isn’t it? That’s the purpose of life, partly. Your life is better. I want to solve problems I meet in the daily life by using computers, so I need to write programs. By using Ruby, I want to concentrate the things I do, not the magical rules of the language, like starting with public void something something something to say, “print hello world.”

The lack of philosophical insights offered by the leaders of the PHP community tends to manifest in ugly ways, especially as a lack of guidance given to beginner programmers about how good code should be written in PHP.

In 2004, Ruby On Rails burst on to the scene, and promised to save us from the complexity of Java and the messiness of PHP. And it was a huge improvement at that time. It offered a structure and elegance that PHP could only dream about, during that time. But nowadays, even Rails is beginning to seem obsolete. Neither Ruby nor PHP are set up to deal with concurrency: they were both designed in the era when computers had just 1 CPU, and that CPU could be relied upon to get faster and faster every year. But the future of computing will be governed by Amdahl’s Law, and neither Ruby nor PHP can offer anything in that direction. jRuby is the future of Ruby, and jRuby is one of the dozens of new languages that people should consider using nowadays. But PHP has no variant that we can point to and say “That is the future of PHP”.

What I wish, above all else, is that I could get people to confront the question “Why would you choose PHP today?” The reasons to choose it in 2000 were compelling, but there is no reason to choose it today — the world has changed, and there are dozens of better choices now.

[ [ UPDATE 2019-09-08 ] ]

Someone on LinkedIn read this and told me “PHP runs half the web and managed to remain backwards compatible. No one is going to rewrite all the code that runs half the web.”

I agree with that: PHP is a painful legacy language that we will have to live with for a long time. But there is reason why you would pick it now, for a new project.

Also, if you are the CTO at some startup and you want to know the mood of software developers in 2019, do consider that in this post about Rails, a debate broke about Rails versus NodeJS and also Rails versus Django. But no one mentioned PHP, because no dev would pick PHP for anything new. This is the mood of your developers in 2019:

I’ve a bunch of small Rails apps running on Heroku and I’ve to say that I’m impressed by the relevance of the new features in the latest Rails releases. Action Text, Active Storage and Action Cable are solving common and painful issues in any web app.
I’ve recently built a web app with Node and the time we spent solving problems which have already been solved a thousand times is astonishing. Things like picking an ORM, having a proper database migration system, running a test suite. It’s actually quite depressing when you come from Rails where everything is working coherently out of the box.

The fact that there is no standards in the Node ecosystem make it a bit more painful. You have to carefully choose between many different libraries to solve your problem. Some of them are in TypeScript, other still use callbacks, etc. We basically had to glue together many libraries to get something working. All those hours could have been spent building the actual product and delivering value to our customers.

Also, reehunter wrote:

I’ve been trying to use NodeJS after using Rails for years and it’s just such a terrible experience. I don’t want to install every basic package by hand and generate every model and view and controller by hand. This is basic boilerplate nonsense that made Rails so popular 15 years ago, and NodeJS throws away every lesson we learned from Rails.

React is okay as a front-end but without a full stack framework, the current state of Javascript is like stepping back into 20 year old PHP development, where everyone just hacks together anything they can find with no structure, no convention, and no security.

Also steve_adams_86 writes:

I recently got up to speed with a rails app remarkably quickly and I agree with all of these points. I found testing wasn’t really a joy, but it was less painful than any experience I’ve had in the python or PHP world. Mailer previews are actually very cool, too. It’s not a game changer but I liked having it and it came in handy.

ActiveRecord was also surprisingly slick. I’d previously mostly used Doctrine and over the years I’ve mostly come to dislike it. AR was fine though and had some features I liked quite a bit. Scopes are really neat. Like any ORM though there are plenty of double edged swords all over.

When I talk to CTOs who do use PHP, they say “PHP programmers are very cheap” which is true, and which I suppose can be rational if you have a project that only requires the cheapest programmers you can find. But if you’re trying to attract a talented team, do keep in mind that they will view PHP as a red flag.