Ruby on Rails and J2EE

January 5, 2006

I have spent some time over Christmas period playing here and there with Ruby on Rails and getting an overdose of AJAX. I really wanted to see whether all the hype and marketing from 37things.com and associates makes any sense.

I have two objectives in mind:

  1. Should I throw away J2EE for Rails?
  2. Should I throw away PHP for Rails?

My impression of Rails has been extremely good so far. However, I am really more pleased with Ruby than I am with Rails itself. Rails is interesting, don't get me wrong, but far from being revolutionary. All concepts and patterns in Rails have existed for a while in the Java and J2EE world for a while now. If so, why is Rails so cool and sexy? I'll give you a few reasons I found for myself:

  • Ruby is a very expressive language for those like us coming from strongly typed language background.
  • Rails makes agile development easy. It is extremely easy to come up with a concept in the morning, and have a prototype in the afternoon to show to your client. This is because development and execution architectures are tightly coupled.
  • Rails principle of convention over configuration works great for 99% of the cases. No need to know how to define or configure something - it just works as long as you follow the principles.
  • Rails provides a really easy-to-use and lightweight structured MVC architecture for those PHP addicts hacking web site after web site.

Would I throw J2EE away now that I encountered Rails? No. J2EE is a distributed component on steroids - so if you don't need distributed components, you don't need J2EE. But if you rely on JMS, JCA, JTA and distributed components, then Rails is not your medicine. Rails is a pure web application framework, with some quick O/R mapping facilities to ease the pain of DB access -- it's great for those web applications only backed by one database custom developed for the particular application. Rails is more of a pain relief for PHP folks than for Java programmers.

If you have been doing pure web frontends in Java using JSP and JDBC, well, sorry, I think you should go back and examine Python (Django), Ruby (Rails) and PHP (Yellow Duck, BlueShoes) and stop wasting your time.

Then there is Trails, a Java replica of Rails, using the "best-of-breed" Tapestry-Spring-Hibernate (yeah, fits my resume). However, I feel there is no much meaning in Trails nor TRAX. If I have complex problems (integration, distribution, transaction management, and messaging), I'll use Spring or directly the J2EE APIs, and will not rely on a generation framework and convention. I will want configuration, and full control.

Finally, there is also PHP On TRAX, a Rails version for PHP. It might have a niche market, for those loyal to PHP. But given Ruby is sooo expressive, why would anybody program in PHP?

Bottom line, Rails and J2EE cover different needs and developer populations. There will surely always be an overlap - and over time they will both mutate to copy features from each other. But it is more likely that we see Ruby 2.0 running on the JVM, than iBatis or Hibernate on Rails!


blog comments powered by Disqus