PHP Is Doomed

It tends to be the case that when there are three or more competitors for something, the race gets narrowed down to two real contenders fairly quickly. In the case of ASP.Net, J2EE, and PHP, I think the odd man out is going to be PHP. "But," you cry out, "PHP is the language of choice for so many open source Web projects!" So was Perl at one point. It did not save Perl, and it will not save PHP. Why not? PHP does not allow the programmer to multithread their application.

I have been doing a series of posts about multithreading techniques with VB.Net (next week I will be posting Part V, using Mutex's for atomic operations). The code is almost directly translatable into C#, and the principles are identical in Java. They will not work in PHP though. PHP, as far as I can tell by searching and browsing its documentation, does not support multithreading. This is going to be a major vulnerability for PHP in the very near future.

One of the major drivers of the Internet explosion has been the plummeting cost of running a server, thanks in large part to the ability of commodity hardware to handle the load of serving pages over the last few years. Between the LAMP stack, J2EE, and the Microsoft stack, there are plenty of options, and they all work very well on a server that can be had for well under $5,000. Up until recently, however, these commodity servers were using one physical and logical CPU. AMD and Intel have changed the game with their dual core (and soon, quad core) CPUs. SMP motherboards have come down significantly in price as well. The $5,000 number can now get you a server that has two dual core Xeon, Core 2 Duo, or Opteron CPUs. In other words, a modern server is at minimum a two logical CPU machine and is headed towards the four-to-sixteen logical core CPU quite soon (two quad core CPUs with HyperThreading is sixteen logical cores). The Sun T1 CPU has put a 32 thread pipeline into the under-$10,000 price range.

Furthermore, more and more Internet applications retrieve – but do not require – data to be retrieved from elsewhere, possibly across a WAN link. If you are a Web developer, would you prefer your application to continue to process its work (for example, retrieving data from the local database, dynamically creating images, etc.) while waiting on the third party chunk of code (such as a Web service), and only have part of the page show a "Sorry!" message? Or do you think it is better for the entire page to take forever if the third party data source has a problem? Personally, I would prefer to process those WAN requests as a separate thread. But PHP cannot do that, because it does not support multithreading.

Sure, PHP supports UNIX style process forking. But the documentation has this to say about forking:
Process Control support in PHP implements the Unix style of process creation, program execution, signal handling and process termination. Process Control should not be enabled within a webserver environment and unexpected results may happen if any Process Control functions are used within a webserver environment.
In other words, PHP, a language that is not terribly useful outside of Web development language, should not use process forking in a Web server. Huh?

PHP is weak in many other areas as well. Its documentation is not very good, and frequently the comment threads provide the information that the documentation should have included but did not. It lacks high quality tools such as IDEs and debuggers in a "ready-to-use" state. I will give PHP this: it is easier to install on top of Apache or IIS than any J2EE server that I have encountered. But outside of that, its only strength was being a Perl-like language (allowing Perl developers to transition to it) while being open source (which neither Java nor .Net are) and being adapted to the Web (which Perl was not). With Ruby and Python in the game, PHP is no longer unique. From what I have heard, read, and seen, Ruby on Rails kicks PHP six ways to Sunday.

PHP is getting hit from all sides, from where I sit. It took RHEL about two years to support PHP5. PHP lacks multithreading support. The .Net Framework and J2EE ecologies are exploding, while PHP5 still feels like a limited knock off of Perl designed to work exclusively with Web pages with a hacky-feeling object model. If you learn Java or a .Net language, you can transition very easily to desktop applications or non-Web server applications; you just need to learn new methods of user interaction. Not so with PHP, it is pretty much so useless outside of a Web server. Meanwhile, Ruby (which does support multithreading) is an excellent general purpose language and the Ruby on Rails framework makes PHP look downright Mickey Mouse in comparison, and it natively supports AJAX (as much as I dislike AJAX, I recognize that it does have its uses, and it is currently quite hot). And Python has been threatening to be "the next big thing" for long enough to believe it may have a chance.

To put it another way, PHP does not do anything that every other language does not do, and it lacks multithreading support, which is quickly becoming a showstopper. If PHP does not catch up soon, I believe that it is doomed. Ruby and Python are poised to take its crown for the open source Web development platform of choice. Remember, Perl and CGI used to own the Web development space entirely; now Perl barely exists in Web development outside of legacy applications. Things change, and PHP needs to change quickly, or it will follow Perl.



Justin James is the Lead Architect for Conigent.

Editor's Picks