Will Ruby on Rails succeed J2EE?

OnJava.com interviews a number of developers to ask them what they think about the idea that Ruby will, at some point, replace Java as the enterprise language of choice. They didn’t ask me, but I’ll do the interview as if they did. (I should do this for more interviews.) They asked all of the people different questions, so I’ll just use whichever questions I like.

1. Why would you choose Ruby on Rails over J2EE for your next Web project?

Initially I was quite sceptical about Ruby on Rails, mainly because of the inordinate amount of hype I was seeing. It wasn’t until I started reading the Rails book that I understood what it offered over the environments with which I was already familiar. The main reason I’d choose Ruby on Rails is that it enables you to get more done with fewer lines of code than J2EE or PHP, and with a lot more structure than with PHP, ColdFusion, or Perl. When you write a Ruby on Rails application, you feel like you’re writing clean code, the way you do with Java, only you’re getting a lot more done with less work.

2. Where’s the innovation in Ruby on Rails?

When I started writing applications in Ruby on Rails, I really enjoyed it, but the question I really wanted to answer was, “What’s innovative about this environment.” The components of Rails are an object-relational modeling framework, an MVC framework, and a templating system not unlike JSP or PHP. In the Java world, we already had a number of excellent MVC frameworks (I’ve used Struts and Spring MVC personally), and a number of well-regarded ORM frameworks (Hibernate is my favorite). There are plenty of systems for embedding code in Web pages out there. The Rails implementations are nice, incremental improvements over what’s come before, but the real innovation results from the “convention over configuration” mantra that is the starting point of Rails design.

Basically, the writers of Rails created a set of rules for properly written applications, and if you follow those rules, you don’t have to tell Rails exactly what you’re doing. The rules mainly relate to naming. If you name things what Rails expects you to, whether they’re database tables and columns, form fields, or view components, you can avoid configuration. I find myself agreeing with all of the Rails rules, so they’re not a hindance, and following them saves a ton of typing.

Anybody could have done something similiar, but Rails was the first framework I’ve seen to take this “convention over configuration” approach, and as much as it’s hyped, it’s even cooler to see how it works in practice.

3. Is there a class of applications for which you’d still use Java rather than Ruby on Rails?

The answer to this question is obvious — of course there is. For one thing, there’s a class of applications where only EJB will do. It would be a project that I’d work on most likely, because I don’t have experience with applications for which only EJBs will suffice, but they are out there. By the same token, one project I’ve worked on had a Web interface, a Web services interface, a batch interface, and lots of deep business logic. It also required fine grained transaction handling that I took care of with Spring. I don’t think I would have attempted that application in Ruby on Rails.

On the other hand, I’m working on a publishing application that I’m writing in Rails. Building it in Java would have just slowed me down.

4. What’s the biggest differentiator between Ruby on Rails and J2EE right now?

The area where Ruby on Rails and J2EE really can’t compare is the learning curve. J2EE lends itself well to writing solid, maintainable Web applications. It also lends itself well to stuffing code into JSPs and churning out unmaintainable Model 1 Web applications. The developer makes the difference. It took me a couple of years of Java development before I really got into MVC frameworks, and longer than that before I started using ORM. Part of that was that MVC and ORM were relatively new back then, and now they’re components of most well-written Web applications. That said, if I wanted to take a new developer and get them writing J2EE applications the way I would, they’d need to pick up Java, JSP, Spring (or some other MVC framework), Hibernate, Xdoclet, Ant, Eclipse, log4j, and probably several other things that I’m forgetting. And they have to learn how to make all that stuff play well together.

In fact, on my current project, there was already a developer here who was going to be working on it. He has some Java experience, but is new to Web applications. He wrote one Web application in Java, using only JSPs. My bet was that it would be easier to get him up to speed on Ruby on Rails (even as I was learning it myself) rather than training him on all of the different Java tools and frameworks that I use and to simultaneously teach him the “MVC way” of writing Web applications. It turned out that I was right, he was working in Rails productively very soon after starting, even though he had no experience with Ruby or Rails previously. That would have never happened had I handed him a list of the Java tools and libraries he’d be using.