What does Ruby on Rails Have to Offer a "Java Guy"?
Submitted by baileyje on Tue, 2007-02-20 06:34.
I have been working as a "Java Guy" for roughly five years now. The majority of my work has been component / library development, and it has been enjoyable on the whole. However, I have also had a few unfortunate “Java web” development projects. These experiences have not been something I hope to repeat often. I am not going to re-describe the Java / J2EE deficiencies in the Web UI layer, but I will go over a few examples of how messy it can get and why Ruby on Rails makes me smile. :)
I will skip all the Java Web UI technologies prior to Struts and JSF. Starting with Struts web development in Java became tolerable. Struts eliminated a couple huge issues I had with Servlets and JSP. Basically I don’t like generating HTML from code, and conversely, I don’t like code embedded in my HTML. Struts separates the two by utilizing the ever popular MVC pattern, mapping Actions, ActionForms, and JSPs in an XML config gile. JSP files remain tidy using the Struts Taglibs.
The problem I had with Struts was the brute-force manner in which it separates the view from the model. Having to create an ActionForm to marshal the data between the request and the Action almost certainly generates a lot of repeated code. In my experience, most web forms represent the data for a given object in the model. Generally there is a POJO to encapsulate date in the model and an ActionForm to encapsulate the data coming in from the request. The ActionForm often times contains almost the same data as the POJO in the model.
Having the data repeated in ActionForm basically requires code to map data from the ActionForm to the POJO before moving forward. This is often done within an Action. Changes to the model will result in a change to the JSPs, ActionForms, Actions, POJOs, Data Access Layer, and Database. So Struts provides the separation between the model and view layer, but now tripled the amount of code / maintenance required.
JSF provides some interesting ways to eliminate several of these issues. Through the use of Expression Language and Managed Beans it is fairly straight forward to map a web form to a POJO in the model. I just need to expose an instance of the POJO through a Managed Bean, and I can use expression language to bind a UI component to the POJO. JSF has several mechanisms to aid the marshaling of the data, but in general it just does it for you. So with JSF we got rid of two piece of code to maintain. Now changes in the model will require a change to the JSPs, POJO, Data Access Layer, and Database.
My biggest issue with JSF is an utter lack of templating. There are several additional frameworks to support this, but I like sticking to standards when possible so I am not really excited to go down that path. All said and done, I think JSF is a good start for Java and Web UI, but it is still very heavy-weight and has a fairly high learning curve.
So where does Ruby on Rails fit in this boring article? Well recently I have been doing a lot of work with Ruby on Rails for my side company. I picked it up as an alternative to PHP for web development. With everything stated above, I have always stuck to PHP for web development on small projects. After some reading I started to get the feeling Ruby would provide me with the comfort I have with OO development in Java as well as a great toolset for web development using the Rails framework.
I have to tell you, I have not been let down. I realized, after about an hour of reading, I could handle the Ruby code with little learning required. A little Googling lead me to some great Ruby on Rails tutorials to start learning Rails. About 11 minutes later I was setup with a simple bug-tracking application. It was pretty ugly, but man I had executed two script/generate commands, wrote four lines of code in a migration file, executed the rake db:migrate commnds, and then the magic happened. I wrote one line of code (scaffold…) in the controller class and I had linkage from the html form to the database.
With Rails a change to the model affects the database and the rest of the components automatically reflect the change.. This is of course a simple example, but it shows how easy it should be to bootstrap a web based application. Once the application is setup, and the scaffold it tested, Rails will allow you to override all the views as needed, which may result in another piece of code. I will take one or two pieces to maintain over four or six any day of the week.
Certain things that are almost always done the same way, so why make me repeat it every time. Rails make these the defaults, but allows any of them to be overridden as the need arises.
Now, there is some contradiction in my assessment Rails and the initial statements I made about web based applications. Rails apps use .rhtml pages for layout, and often requires Ruby code embedded in the file. It is however manageable with the small useful commands provided by Rails. View pages have little code without having to use a heavy-weight framework for marshaling the data from one layer to the other. All the other benefits of the framework far outweigh the issue of code in the view.
Rails also make it easy to get data into your view pages. If an object is referenced in the Controller method for the request, it is accessible in the view. This provides almost Expression Language like abilities. Add this together with the built-in simple but powerful Object Relational Mapping and Ruby on Rails has everything you need to build great web based applications.
So overall my opinion on Ruby on Rails is very favorable. I would suggest anyone interested in web development to take a look at it, but more importantly I would suggest that anyone looking to improve Java’s web UI frameworks to take a look.
Simple is better in all cases…