Comparing Frameworks: Java And PHP

On Wednesday in Frankfurt at the PHP International Conference I gave a fairly general talk on issues in Web frameworks. I had fun making a graph comparing Java, PHP, and Rails, and you might enjoy it too. [Update: Theserverside.com has a grossly inaccurate flame-bait take on this, and won’t let me sign in to comment; won’t take my password, and also won’t take the one they email me when I say I forgot. Grr.] [Update, February 2007: There’s now a Korean translation by CHOI Jae-Hoon; thanks!]

The Context · The problem at hand is Web Application Building. Thus we are not considering general issues of compute performance, because in Web apps, you don’t do much computing. You get some values from the browser, you use them to pull some info out of a database, you report them to the user, maybe you update the database, and that’s about it. ¶

Here’s the graph, followed by some applications.

Scaling · If you’re actually doing any computing, Java is obviously the fastest. For running web apps, the maximum scalability is probably about the same, because there’s not much computing there. After all, Java runs EBay while PHP runs Wikipedia and Yahoo! Finance. Both clearly scale “well enough”. ¶

For Web apps, I’ve given PHP the edge, because I think building scalable PHP is a little easier. By default, PHP gives you a “shared-nothing” (or at least “shared very little”) architecture, which means you’re going to scale out pretty well until your database hits the wall. Java is a much richer system and assumes you’re smart enough to know whether a shared-nothing architecture is appropriate or not. The effect is, you have to be smarter to get the same kind of scaling out of Java.

As for Rails, I think it’s probably the case that you can build a Web-scale app, just like Java and PHP, but we don’t know because nobody’s done it yet. Also, we have to penalize Rails a bit because most apps end up having a little computing in them, and Ruby is quite a bit behind the alternatives in that department.

Development Speed · The question is “All other things being equal, how fast can I get my Web app on the air?” I think Rails has set a new benchmark here; you keep hearing astounding stories of serious applications going up in days rather than months and weeks rather than years. ¶

Having said that, Rails’ sweet spot (CRUD-oriented greenfield apps) is well-understood; but still, it seems obvious that Rails has some lessons to teach that the rest of the frameworks would do well to learn from. And I’d argue that the current direction of Java EE is evidence that that learning is happening.

PHP’s original claim to fame was that it was the quick-and-dirty way to get a Web app on the air. There’s no point trying to sweep the “dirty” bit under the carpet; a lot of those quickie PHP apps are butt-ugly. One of the reasons Rails is interesting is that it’s quick and clean.

Developer Tools · Application building and maintenance isn’t a sprint, it’s a marathon. Your overall results in the long term are going to depend a lot on the quality of your tools. Happy developers are productive developers. ¶

Java is the obvious winner here, by a mile. Granted, Rails has TextMate and PHP has the Zend stuff, and while there is work over in Eclipse to add support for both PHP and Ruby. But the comprehensive, integrated, polished, fast support that a Java developer gets from NetBeans or Eclipse or Idea is miles beyond any of these things. I’m not really up-to-date on Eclipse or Idea, but if you look at the recent NetBeans 5.5, the amount of automated support for Web-app development is astounding; if I’d been graphing NetBeans instead of Java, I suspect it’d have equaled or passed PHP in the development-speed department.

Maintainability · Good apps, once built, tend to be in production for an astonishingly long time. Which means that they have to be maintained for an astonishingly long time. Which means that maintainability is important. There are a lot of things that go into maintainability, but I suggest that the biggies are object-orientation, MVC architecture, code readability, and code size (less is more, a lot more). ¶

This is PHP’s Achilles’ heel, of course. Yes, it is possible to write clean, object-oriented, modular, MVC-style PHP applications. But most people don’t; the majority of apps that I’ve seen have spaghetti PHP code wrapped around spaghetti SQL embedded in spaghetti HTML. Also, a lot of the people who really understand O-O and MVC and maintainability would rather work in Java or Rails.

I’ve put Rails ahead of Java just because there’s so much less code. The maintenance cost of code is strongly related to its size. Clearly, Java’s excellent developer tools make a difference, but still, I think that this is another area where Ruby and Rails are teaching lessons the rest of the industry would do well to learn from.

Omissions · .NET and the Python frameworks, starting with Django, are notable by their absence here. Sorry; I just don’t have any first-hand knowledge on them. And .NET isn’t open-source, so why would you use it? ¶

Irritants · I’ve already got people mad at me, because they think I said “PHP is faster than Java” (I didn’t) and because I said Rails is faster to build and more maintainable than PHP (I did, and I stand by it). ¶

Obviously, there are edge cases; I’m sure you can find examples where Rails runs faster than the alternatives, or a Java app can be built fastest, or there are superb PHP dev tools for some type of app, or there’s a horribly-architected unmaintainable piece of Java framework crap.

What Matters? · The question “Which of Java, PHP, and Rails is best?” is just silly. The answer, as with so many engineering questions, is “it depends”. My personal opinion is that for most Web apps, scaling isn’t really a good basis for making a choice; if you have a decent application architecture, you can make any of these scale enough, and if you don’t, you can’t. ¶

In recent years things like PHP and Rails have taught us that development speed is more important than we thought it was. On top of the obvious business value of delivering functions faster, there’s the Agile/XP view that you really don’t understand a feature till you’ve built it, so the faster you can build them the faster you understand them.

Developer tool quality is something you ignore at your peril; application development and maintenance is an endless grind, and you’re going to be a lot happier at work, long-term, living in a tool like NetBeans or Eclipse.

Maybe it’s just because I’m a grizzled 25-year veteran, but my feeling is that in the real world in the long term, maintainability is a really really big deal, the biggest of all.

Out there in the wild woolly “Web 2.0” world, maybe getting it built quick is all that matters, because after you’ve knocked ’em dead and been acquired, you can use the money from the Yahoo! buy-out to rebuild everything right the second time. In the enterprise though, I kind of suspect that smart developers and smart managers know that for real apps, the big development cost starts to happen after they’re delivered.

Whatever; you have to make your own choice based on your own application, business, and people constraints. That’s not controversial.

PS: Integration · This stuff was only about half my talk. The other half was about integration; your stack’s internal integration, about integrating with Identity technology, and about the general problem of heterogeneous framework integration across the network. That part was actually more interesting.

So In what language you are working on??