Why Grails matters? That’s a fair question if we take a look at the huge amount of web frameworks an average Java developer is used to. Behind this question actually there’s another one hidden: “Does Grails really brings something new or is it just another web framework?”.
Historically speakng, we can see that the only really revolutionary web framework on the Java platform is Struts. Not because is the best, but only because it was the first (at least that I know). After Struts we can see the amazing proliferation of zillions of web frameworks, all promising the same thing: “revolutionize web development through huge gains in developer productivity”. Some really did it (but MANY more didn’t), and at the end of the day, there was this feeling that they actually didn’t bring anything new (with some exceptions, like VRaptor, Tapestry, JSF and some others).
So the question is: will Grails be only one more in the list? And my answer is: no! That’s because Grails brings some new technology, but more than that, Grails bring us a “new” work philosophy.
This “new” work philosophy is actually inspired on Ruby on Rails (RoR). Just to remember, Grails is not the original name of this framework: Groovy on Rails was. When RoR started to became popular, it was like a slap on the face of MANY Java developers. Suddenly, our methodology and tools became amazingly lame (maybe “bored” should be the word). And in that same moment, some JEE problems became crystal clear to everyone.
Hard component integration
If you’re a Java developer you know that we have at our disposal some tools like Hibernate, Spring, Log4j and many others that are simply marvelous. They really improve our productivity, but when we have to integrate them, it’s usual to see all this gain fading in front of us.
There are actually too many jar files to manage. It’s really common to face problems like incompatibilities, version problems and so on. Really a pain in the ass many times.
Configuration files
It’s amazing the amount of time spent on these beasts. We have to configure our servers, the application context, framework behavior, managed beans, tag libraries and so on. And all these things are made using XML files, is a great format, but whose syntax is basically the opposite of the one we are used too, is the Java’s syntax.
It’s true that we can avoid these files if we are using a great IDE, but this is only a silly illusion. You know that some day you’ll have to face these bastards.
Repetition, repetition, repetition and more repetition
If you’re working on a simple CRUD application, the repetitiveness becames clear. Usually you have to create basically four pages for each entity: one for editing, another one for creating, another one for listing and, finally a page will show the details of that register. So, if you have N entities in your application, you’ll have to write approximately 4*N pages.
And what is more sad: basically, these pages are all very much the same. The only change is fields are being exposed. Whould’nt it be nice if you could build these pages automatically?
Stack configuration
Here is the situation: a new programmer arives at your office and you need to setup his environment. So, there are two options: you already have an image ready to be used or you don’t. In the second case, you know how boring this is: you have to install JDK, IDE, libraries, servers and so on. Even worse: sometimes you have to configure the developers IDE to work properly with the components you’re used to.
Of course, someone could say: “but if you install an IDE like Netbeans, all this stuff are there ready to be used”. Well, this is only half true: things are not so beautiful on the real world.
Ruby on Rails (and Grails) philosophy
DRY: Don’t Repeat Yourself
The question is: if there are tasks are repetitive in the development process, why they are executed by humans and not by the framework?
After all, developers are paid to implement a business model, not to execute repetitive tasks. At leat in theory they’re paid to THINK!
At RoR we can see the return of something that we had simply ignored: scaffolding. The framework generates automatically for the developer several artifacts are usually related to repetitive tasks, like for example views and controllers. So, all the repetitive tasks are gone, and your work will be to only customize these artifacts. Neat!
(where we had seen this before? Personal databases like Access (damn!), Paradox, FileMaker and many others)
Convention over configuration (or zero configuration)
Here is where productivity soars. You don’t need configuration files if everything is in its place, do you? When working with RoR or Grails, the framework will stipulate some conventions that simply make configuration files unnecessary.
For example: in Grails every controller is stored on a specific directory. So, it’s not necessary to told the framework are the controllers. He’ll find them automatically. Actually, when working with Grails and RoR, it’s quite common that the only configuration file you’ll ever touch will be the one is responsible for defining the dabase access configuration!
The basic idea here is: configuration files are unnecessary because the application is already well organized. The configuration, in this case, is the application itself!
But, more than that, it’s important to think in conventions over configuration, and not instead of configurations. Why? Simple: because these applications usually are targeted at the enterprise environment, so you’ll have to integrate them with it. So, in this case, you’ll have to change some configuration files, but guess what: it’ll be far easier, because in these cases, you’re not working with XML.
Full stack
As RoR, Grails installation is actually an IDE with everything you need. To install it, all you need is the JDK and Grails installation (of course!). You don’t even need to concern about installing some other IDE or server. All you’ll need is a simple text editor.
And in Grails case, it is based on several components whose quality is already attested like Hibernate, Spring, SiteMesh, Log4J, Apache Commons and many others. So you don’t need to worry about how to integrate those libraries and frameworks, because they already are! Again, all you need to worry is your business logic!
So, after all this talk about RoR, and knowing that “something” called JRuby exists, the question is:
Why Grails and not Ruby on Rails?
Actually, it doesn’t matter. Your productivity boost will be basically the same. However, for the Java developer, already used to it’s syntax, Grails will be way more familiar, because it’s based on Groovy, , by the way, have basically the same Java syntax (with some syntatic sugar). Your learning curve will be reduced on this case.
Another important point is the fact that you’ll be able to reuse all your legacy code on a Grails project without changing anything on it ( is not a Grails advantage, because this same code reuse can be achieved using JRuby too).
But, at the end of the day, this can be solved with a single question: language do you prefer? Grovy (Java) or Ruby? Java? Go Grails! Ruby? Go RoR!
Finally answering the question: “why Grails matters to a Java developer?”
After the success of RoR, the problems of the JEE platform became clear to everyone. Even if Grails or RoR suddenly disappear, from now on the new frameworks that will emerge will be following this “new” philosophy. And taking into consideration that Grails was developed since it’s begining focusing on the Java developer, it’s an undeniable fact that it will have a huge influence over all the new developments on this area from now on.
Or, being more direct: because RoR and Grails suddenly showed us that working with the JEE is amazingly boring.
Deixe uma resposta