It’s easy to complain about PHP. Look, here’s Jeff Atwood complaining about PHP. He proposes to create something that will replace PHP. I’m all for this project — as an industry, we should constantly be working to improve and replace things, and we should be building great things in case they do wind up becoming popular.
If you’re going to try to replace PHP, you need to figure out what it is about PHP that enables it to maintain its massive market share. Everybody knows about the friendly learning curve and the easy availability of inexpensive hosting. If you want to create your first Web application, PHP is the simplest way to get started.
What’s interesting, though, are the reasons why you see some of the biggest Web sites deployed on PHP. It’s not because developers love it. It starts with the fact that PHP is easy to operationalize at any scale, or at least easier than most other technologies. It doesn’t require an app server, or a virtual machine, or anything that’s outside the realm of basic Unix processes.
What’s more important, though, is that many of the most experienced ops people in the industry who have deployed large scale sites have a PHP background. They understand how PHP works and where it fails. Building that experience on a different stack would take the same thousands of hours that they’ve already invested in learning how PHP scales. It also seems to me that you see less scaling-related drama from PHP-based sites than you see with sites that try newer technologies, or eclectic mixes of technologies. We’ve never seen Facebook go through growing pains like Twitter has gone through.
If you’re working on something with the goal of displacing PHP, the Twelve-Factor App manifesto is not a bad place to start. The other option is to build something that runs on top of the JVM, because there’s a lot of operational expertise in that area as well.
That said, the simplicity of PHP from an operations standpoint and the deep experience with it will make it somewhat difficult to displace PHP from its current position in the industry, no matter how much programmers like to gripe about it.
June 30, 2012 at 11:49 am
After reading about the ways devops works at Facebook, I would say that they went to great lengths to scale out of their growth problems. A 1.5GB compiled binary of the Faceapp “app” sounds crazy. This isn’t to say they’ve had Twitter-like problems, just that they’ve had to put similar energy into solving the problem…luckily without an entire flip of the infrastructure language. In a lot of cases, they invented their own solutions.
June 30, 2012 at 12:33 pm
I know zero about creating a programming language but if you can build on top of the JVM it would be cool if you could just build on top of PHP. I would be more apt to try new languages if they just worked in my shitty dreamhost shared box.
June 30, 2012 at 3:29 pm
Facebook has certainly moved past any sort of traditional scaling approaches for PHP (or anything).
July 1, 2012 at 3:00 pm
Have you taken a look at haxe.org? One of it’s compile targets is PHP, as well as HTML5 / Javascript, and Actionscript.
July 6, 2012 at 10:17 am
You have never created enterprise software, have you? PHP is a mess of spaghetti code in large enterprise apps and doesn’t have nearly any useful libraries for serious high-power scientific computing. There have been well documented issues with the Facebook implementation, so much so that they created their own custom version and several of their developers and engineers have admitted that the PHP/MySQL backbone is essentially strung together with the programming equivalent of “duct tape.” Its a language people start out with because its cheap and easy to learn, but it lacks any sense of being a high-performing enterprise language like Java or C#.