Web Development

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.

J.Ja

About

Justin James is the Lead Architect for Conigent.

16 comments
abhijitkanade
abhijitkanade

Before reading this I had similar thoughts but anyway I got encouraged now because someone is with me. :-)

Jaqui
Jaqui

I don't agree that it is doomed, but I do see your point in threading. [ the site hanging while getting content from other servers here on TR is a strong arguement for threading ] Java as a language of choice for web applications? when it noticably slows down a dual core 64 bit system to install java support? not by anyone with two braincells to rub together. .net? only if you have thousands of dollars to throw away buying MS server to power it. perl is dead? really? have you ever visited a site called slashdot.org? 100% perl

rubinthomas
rubinthomas

Hey Since your so concerned of hard ware requiremnt rather than software requirement. try doing an "eval statement" dynamically to assign values to variables in .net or java and come back with a solution with how many lines of code you will write and process to make it work...thats why you require quad core processors to do that while php will run on a p2 machine and deliver the same out put faster than ur quad core machine and your threads executing.

GreyTech
GreyTech

I think there is a need for a web server side language that non-programmers can handle for small applications. PHP fills that role. It may not be the right language for large applications but it suits many small business website designers. I am not a programmer, although I did cut my teeth on 8008, 8080 and Z80 assembler code, a little basic and a lot of .bat and kixstart scripts in more recent years (since the advent of DOS). Simple JavaScript suits some web design needs and PHP others. KISS needs to apply sometimes. Other times strong manageable structure is needed. There is a place for both. The problem as I see it is that the language developers always want to enhance the language to be a Swiss Army Knife instead of keeping it suitable for its target user.

big-b
big-b

I don't much about PHP but from a client's perspective, our developer did a nice job developing a couple of dynamic applications. He built a great Dashboard and CRM applications with very rich user front ends. Sure the front end user experience has a lot to do with the AJAX involved but the workflow with what happens to data after it is manipulated by the user is done with PHP in the back end.

wiseman1024
wiseman1024

That's what Microsoft and Sun would like. Unfortunately for them, PHP is here to stay. PHP is designed for web applications, and as such, it can't be criticized for not being optimal for desktop applications. It's the matter of the right tool for every job, and speaking of right tools, Java doesn't seem to have any sweet spot, as it's cumbersome and unproductive anywhere. PHP's productivity ranges from 5 to 10 times more than Java, and provides better tools - native, immediate lists and dictionaries, dynamic typing, dynamic functions, and a huge open source codebase - for web applications. But back to PHP. Multithreading is not necessary because it's implemented in the web server. You can exploit 32 or 64 pipeline machines through concurrent queries. You shouldn't need threads to attend one query, and you shouldn't want that complexity. If you're depending on web services so slow that you require threads, then you're not doing something right: remember the web service still has to finish for the query to finish, and if it takes one second (a shamefully long time for a query in a decent application), and everything else you do takes 50 ms, then I wouldn't bother using threads to save 5% of the time; that'd be a needless complication that doesn't attack the bottleneck which the web service is. Face it, as much as web services are on the buzz and management people keep filling magazine articles with it (regardless of the fact very few actually understand them), web services are not designed for efficiency. If you were worried about efficiency, you wouldn't be writing and reading XML, would you? (Oh, but they just had to use XML. It's another business buzzword.) As far as PHP features go, I'm more interested on getting first-class functions, closures, proper syntax for anonymous closures/lambdas, namespaces, coroutines and generators than threads. Sure, threads would be nice, but they rank lower in my list, because they are hardly necessary for web application development, and that's what PHP is for. As for Ruby on Rails: Ruby is a nice language which, as a language, is superior to PHP, Java, C# and VB.net, only comparable to other modern languages such as Python, Lisp or JavaScript (not snippet copypasta JavaScript, or what people think JavaScript is, but JavaScript, as in JavaScript). Rails is a great productivity framework, and has the advantage of being a de facto standard framework, something PHP doesn't have. However, it also has a much worse learning curve, and forces you to work using the MVC model, which is not optimal for large applications and complex queries, where it tends to introduce needless complexity or needless application-side processing.

rpitera
rpitera

PHP is not going anywhere, nor is it doomed. If you have any doubts, take a look at the SERIOSULY ugly source for this very page, written in something obviously other than PHP. :) I remember a few years ago when we were told html was 'doomed' by xml, and that Windows was 'doomed' by the Mac or Linux...and we all know how accurate *those* predictions were.

wiseman1024
wiseman1024

Just a note: I said Ruby, as a language, is only comparable to other modern languages such as Python, Lisp or JavaScript. Note that Lisp is by no means modern. Python, JavaScript, Lua, etc. are. (In fact, most of these langauge features were introduced decades ago on Lisp.)

apotheon
apotheon

HTML is being replaced by XML right now. Most new webpages are being produced in XHTML, rather than HTML. XHTML is XML within specific constraints designed to mimic much of the form of HTML. Give it time. Short of legislation that gets the US government to prop up Microsoft's Windows market dominance, it will give way. I'm not predicting it'll happen today, nor am I predicting that a specific OS will be the replacement -- but I'm predicting that it'll happen before too many more years go by, barring governmental interference in the process of Microsoft's eventual failure within the OS market.

TechExec2
TechExec2

Something is doomed: PHP naysayers!

Fuzi0n
Fuzi0n

HTML isnt being replaced by anything, but then again I dont see it being updated from version 4 either, BUT NOT REPLACED. Both HTML and XML are a subset of Standard Generalized Markup Language (SGML). XML works WITH HTML and each has their own specification (Logical / Physical) structure etc. Or maybe an email should be sent to the W3C HTML Member Working Group and tell them they are no longer needed? Im also trying to figure out how legislation and Operating Systems will affect PHP? What were u thinking there?

donengene
donengene

in the late 90s I was involved in developing kiosk applications with Speedware (not all that different from PHP), and it did make things accessable to non programmers that knew HTML to be able to edit pages. The day has come when HTML is known by a lot of people and to loose a language like PSP that uses a lot of stright HTML templating is just a bad idea. The opensourcing of Java is to blame, I think most people are short sighted about the open sourcing of Java. You think BEA will give away its business. Sun seems to be trying to gain the best ideas from open sourcing the product much like Apple did with Darwin and then close the open source so it can sell a better product without having to have paid for the developemnt. Wake up and smell the Java Beans, McNealy has always tried to make money by giving stuff away then charging for it later, he is like a crack dealer the first hit is free, oh you want more you'll have to pay for it, even though my guy in the back room is making it for nothing probably from a 3rd world country.

apotheon
apotheon

"[i]As a language, PHP is lacking.[/i]" True. "[i]I would prefer to see it require explicit variable declarations and static typing with explicit type conversions.[/i]" Holy mother of God, is that a bad idea. That would destroy PHP's usefulness as a templating language -- the only use for which it provides any value. I think you may need to expose yourself to a language like OCaml as a baby step toward appreciating dynamic languages. OCaml is not a dynamic language at all -- it is both strongly and statically typed (whereas languages like Pascal and C++ are weakly and statically typed, the worst of all worlds). It handles its typing far better than C/C++, Java, or Pascal, however. OCaml might serve as a baby step toward appreciation of dynamic languages, however, because it uses a modern type inference system, rather than the positively paleolithic type declaration system of languages like C. You need never explicitly declare a type in OCaml, but you always know what the type is, and it's a strong type. Beautiful stuff. Ruby, meanwhile, is dynamically and strongly typed. It is, in fact, "duck typed". I'm pretty much of the opinion that the best way to handle typing in a language is (depending on the language) to design it according to one of the following three general categories of type system: 1. A single core type, with types that can be defined on the fly and made dynamic or static as desired, like in Lisp. 2. Duck typed, where a type is born when it's needed -- dynamically and strongly typed. 3. Strongly and statically typed with a modern type inference system so I don't have to write reams of type declaration and management code that the compiler should be smart enough to handle, just so I can get decent compiled binary performance.

Justin James
Justin James

The PHP system as a template system is a lot easier to work with, and lot less powerful than ASP.Net or JSP or EJB or any of the alternatives. For a small site, the shortcomings of the template system do not show. Where PHP is woefully lacking, is what language gets used within the templates itself. It is a mediocre language at best. It feels like the worst of Perl without any of the good parts of Perl. No thank you. If you want to use a Perl-ish template system, use a Perl template system, or use Perl + the CGI modules, or craft your own template system in Perl. It takes about 10 total lines of code to replicate the 80% of PHP's functionality that commonly gets used in Perl. PHP is not even close to being something that I would want to use on a big project... that is to say, anything with more than a few dynamic pages. Just look at the awkwark hacks that most PHP sites use for internationalization or localization, to get an idea of what I am talking about. Look at the mangled code most PHP applications go through to make themselves themable. It is a mess. PHP is neither a stellar template engine, nor a stellar language. If it meets your needs, great. Stick with it, and enjoy! But it lacks just about every feature and method that I would have on a punchlist of things I would want on a big project. Starting with multithreading, and ending with the fact that all it really is, is a simple swapping of STDOUT with a network socket, and at the end of the day, everything is done with the echo statement... J.Ja

TechExec2
TechExec2

. I agree. As a language, PHP is lacking. In particular, I would prefer to see it require explicit variable declarations and static typing with explicit type conversions. This is something I have always liked about Pascal. And, I would like to see it have C-style try..except..finally blocks for all exceptions including PHP ones. I never get everything I want. :-) On the plus side, I like its ubiquity and function set that is so well tailored to sending out dynamic HTML. I also like it much better than anything I have seen from Microsoft for server-side coding. I haven't worked with Ruby, but plan to give it a look. I keep hearing a lot of good things about it.

apotheon
apotheon

PHP is much, MUCH better than Microsoft alternatives, and it provides something that until very recently nothing else provided -- a widely available web development templating language. Luckily, things are changing, and we'll increasingly have better options for web development templating languages. For instance, you can use eruby to provide Ruby parsing from within Apache without having to install mod_ruby, so that you can do your templating development with Ruby instead of PHP. Much, MUCH better. PHP might still "go away", at least to some extent, thanks to the increasing availability of such options. Then again, it might not. If it doesn't go away in favor of something like Ruby, I may have to shed a tear. PHP is a pretty crummy language, all things considered.

Editor's Picks