June 25, 2008
Today I was working on a Rails site where users have profiles that anyone can view, but if you are viewing your own profile, there are links on the page to edit various parts of the profile. I want the links to show up if you are viewing your own profile, but not be there if you are viewing someone else's profile. To implement this is trivial, as any Rails developer would tell you. I simply added a helper method:
if current_user == @user
link_to title, url, options
And changed the occurrences of
<%= link_to "Edit", edit_something_path %> to
<%= link_to_if_owner "Edit", edit_something_path %>. This probably took 15 seconds, and could not be more clear and succinct. When I compare this to doing Java/J2EE development, this task would probably have involved a custom JSP tag and would have been a complicated solution with much ceremony.
This is what is referred to as the means of abstraction in SICP. They assert that the power of a programming language or framework should be measured by its means of abstraction. The means of abstraction is how you take a set of operations and build a smaller operation that you can build on top of. This is just one example of many that shows why Ruby/Rails is a more powerful combination than Java/J2EE.
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.