The Ruby end-run

It was fun while it lasted, but PHP’s time may have come and gone. The benefits of PHP in the early days (extremely fast prototyping, embedded in HTML) outweighed the problems (haphazard function naming, poor object-oriented features, and difficulty designing large applications).

PHP Everywhere discusses the move to more robust object-oriented features to compete directly with Java. But some of the old design decisions cannot be swept under the rug. They will remain, leaving an awkward architectural mess.

Web applications are not like traditional applications, where you make an investment in a programming language and source code that makes it all but impossible to change. Web apps are constantly evolving, being rewritten. Or they are obsoleted, shelved. A new domain name is registered and the process starts again.

Enter Ruby on Rails, simple and elegant, drawing the best from the PHP and Java camps. There’s been a lot of criticism from the Java world, but many of those people write code like it was a traditional application anyway — big, complex, connected to legacy systems. They are too invested to switch, and that’s fine.

But the PHP people will switch, easily, and with the apparent momentum of Ruby right now, maybe it’s already happening. Forget the enterprise for now. Rails is a perfect fit for anyone who develops for the web on its own terms, and the people behind apps like Basecamp, 43things, and the upcoming Odeo match that profile.

Update: Dan responds with further exploration of PHP, Java, and Ruby, focusing on why Ruby may not be well suited as an introductory programming language.

Manton Reece @manton