During the last years there’s been a trend in many developers to gravitate towards languages such as
Some new technologies emerged, inspired by Ruby on Rails. Grails, Spring Roo and Play Framework. What do they propose?
During the last years, there’s been a trend in many developers to gravitate towards languages such as Ruby, Python, and PHP that offer quick solutions for the development of web applications.
In this context, some new technologies emerged, inspired by Ruby on Rails. Grails, Spring Roo, and Play Framework. What do they propose?
Follow the red brick path
Ruby on Rails opened a path that other languages didn’t take long to follow: an open-source framework for web applications, whose goal is to improve the productivity and happiness of the developer. Its motto: “Web development that does not hurt”. A framework that is fun to use.
A framework that avoids unnecessary configurations. Why do we need them so much? We all know that at the end you end up configuring pretty much always the same things. Following the precepts of convention over configuration, leaving only what s “fun” in hands of the developer and avoiding the “tedious” part of the configuration by accepting the defaults the framework provides.
The Java community was slow to react, Ruby has been around for more than five years, but it slowly began to respond, and many frameworks of the same principle sprung up. These frameworks have the same premise that made the 4th generation languages strong in the nineties: Devote themselves fully to commercial software development, improving developer productivity. But where the 4GL languages focused on abstracting the developer from “low level” issues, these frameworks seek to free the developer from all the configuration responsibilities and make him deal directly with the juicy stuff: the business model, always within the confines of a 3GL language.
The Last Crusade
Grails is a clear example of one of these frameworks, inspired even in the name by Ruby on Rails. Grail
s is a framework created by the springsource folks for groovy, a dynamic language that runs on the java virtual machine. Grails is a “quick” framework, dynamic and robust. “The search is over” they promise, a clear reference to the crusades and the Holy Grail, and, at the same time, to our search for the framework that allows us to do a web application in just a few minutes.
Jump, little kangaroo!
But Grails still wasn’t Java. It was Groovy. So springsource, once again, came up with a new solution: Spring Roo. What is Roo? Not a framework, not an IDE, but something in between. Spring Roo is a tool that promises quick and easy results when developing web applications. And the most important part: it is pure Java. “Making Java fun” is its motto, prioritizing once again the happiness of the developer. Were we having such a bad time?
Roo allows us to have a running web application written in Java in just a few minutes. Everything is done by working inside an interactive console, with autocomplete and a handy “hint” option, just in case we get lost on how to proceed. As if this wasn’t enough, Roo gives us an offer that is hard to refuse: if at any moment we don´t want to use Roo anymore, we can completely remove it from our application following a few simple steps and everything will keep on working as before. “No lock in” they say, “not married” we would add.
At first sight Roo can scare more than one, too many files are created for each class and it makes extensive use of (for not saying abuse) of aspects. I could even say that it is essential to understand aspects in order to work with Roo, but I wouldn’t go that far. An IDE exists called SpringSource Tool Suite, or STS, that is based on Eclipse and that perfectly integrates with Roo. The STS almost makes us forget about the number of files and the usage of aspects, but sadly it is remarkably slow and that may cause some frustration.
Roo integrates and supports a big amount of technologies, and this list grows every day. Just to give a few examples we can mention Google Web Toolkit, the Google App Engine and several of the Apache and Spring projects. Could this be the main strength of Spring Roo? Could this distinguish it from all the other tools?
Won’t you come out to PLAY?
Looming on the horizon is Play Framework, with a completely different approach, but with the same goal. Play also allows us to code in Java (and pretty soon in Scala) and to forget about the tedious “initial configuration” of every project, but Play is not just another development framework. Play’s strength lies in the fact that it is also an application server, and one made with the idea of developing while having the application deployed. Play provides instant code replacement with no need to restart the server, and it shows errors and stack traces in the browser, so you can see them easily.
This feature helps the job of the developer as it prevents losing valuable time while debugging and bugfixing. Something to consider is that Play has some “eccentricities” that will bring headaches to the more “traditional” Java developers, for example, a large number of static methods, or the need for public attributes. A different solution to the same problem.
But what if I dislike something about the framework?
What should I do? Each framework has, obviously, its limitations. What would happen if I need to have a service layer? And what if the framework does not encourage it but I really, really, want to use DAO’s? The question we should ask ourselves is: what concessions am I willing to make?
Every framework allows us to change something, but not everything can be changed. And that’s when we should make a pause and decide whether we are willing to give up some control of the architecture to the application framework in order to benefit from its advantage, or not. As always, it depends mostly on the problem we are trying to solve.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
