March 15, 2007
I know, I know, here we go again, another blog post about Ruby on Rails vs. J2EE. Get ready for a flame war. Why do I say that? Because that's what Ruby on Rails vs. J2EE discussions usually turn into. But today I ran across a really good short comparison of Rails and J2EE by Bruno Fernandez-Ruiz. Here's a great quote:
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.
But don't take that quote out of context, because here's another thing he says:
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.
And to sum it up:
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.
This points out how Rails and J2EE are different tools, and one can be better than the other, depending on the requirements of the application. Rather than spending time defending whichever one you happen to be better at, spend time learning more about the other, and learning about which kinds of applications each is appropriate for.
Another thing to point how is that how each platform has the opposite challenge. J2EE has the problem of dealing with how to scale down in terms of complexity. Simply put, simple applications are more difficult than they need to be with J2EE. Rails on the other hand has the problem of dealing with how to scale up in terms of complexity. Rails is great for straight-forward database-backed web applications, but what about dealing with applications that have complex transaction management issues? Using either framework in the wrong situation will result in your application falling victim to the Bittersweet Motel Syndrome.