How to usurp PHP’s place: an outline

Sunday, 21 Sep 2008

Recently, I got mail from someone who read my opinion piece about PHP and inquired about my closing line:

PHP is ripe for having its lunch eaten, really.

The question obviously suggests itself: by whom? The answer is, I don’t know. There is no obvious candidate. I do however think that I know what such a candidate would have to look like.

It will have to be more than just a programming language, because PHP itself is really more than a programming language. It includes a crude web framework (an invocation model reminiscent of CGI, with extensions) plus a crude deployment solution (just make all the libraries part of the language and let the sysadmin worry about it – who in turn often defers to his operating system vendor). This is PHP’s way of taking the worse-is-better philosophy to dazzling new depths:

  1. It provides everything necessary for writing web apps, by default. The functionality may not be particularly well designed, and contemporary trend among seasoned PHP developers may be to spend more time working around it than with it, but it’s there. As a developer, you can rely on it – if PHP is there at all (and nowadays, where is it not?), so are these features.

  2. If you are a user interested in an application that is written in PHP, all parts of application deployment other than uploading the application code itself are Someone Else’s Problem – namely the system adminstrator’s. This means PHP apps can be installed by almost anyone who can buy web space, because they need to know nothing about either programming or system administration.

This recipe has very obviously been a resounding success.

So I think whatever eats PHP’s lunch is going to be a standardised programming environment rather than a mere language by itself – one that might conceivably even be language-agnostic, though in that case platform features among participating languages will likely have to be reasonably similar. An example of what I am thinking of might be Google’s App Engine. While it uses Python, it’s much more than just web hosting with Python support. We see the same principles in action as with PHP: all the bits required by web apps are included, and the installation of any libraries is Someone Else’s Problem as far as the user is concerned.

Note that I’m not saying App Engine is the PHP killer (or even a PHP killer). It could become that, if web hosters were to start providing App Engine hosting and people were to start writing App Engine apps that are so good that non-programmers want to run them. And it’s certainly a possibility that this will eventually happen, even if at this point it seems rather less likely than it might have at the time of App Engine’s unveiling. Google have provided everything necessary for other companies to copy App Engine, and as long as its popularity is low, they can afford to keep it around indefinitely. (What if popularity does surge? Why, mission accomplished of course.)

But however the future of App Engine may turn out, it is a useful rough outline of what usurping PHP’s place would take. It’s also a useful reminder that the technologies commonly considered to compete with PHP in the market actually occupy a very different space.