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.
Grails is especially interesting because it’s “testable from the very beginning” – grails philosophy and some plugins (for webtest, selenium etc) facilitates the functional tests. You get for free something that requires a lot of effort in a “normal” JEE project. For me that is something really important.
thanks for interesting post
Tomek
@Tomek, That´s a really good point Tomek! And I should had mentioned that on the post.
“Actually, it doesn’t matter. Your productivity boost will be basically the same.”
Honest question: does Grails support method chaining (filters), class body code execution (filters, relationships, acts_as_ ), and other robust metaprogramming constructs (most of rails)?
If it doesn’t then it may not be fair to say that the productivity increase will be the same. A lot of what Rails does to make it easy to use is directly dependent on Ruby’s amazing malleability as a language.
@John Bender, Hi John, I agree with you when talking at the language level, but at the framework level, I’ll have to disagree, because the average RoR or Grails user will not use these meta programming capabilities of the language at all.
All that matters for this average guy is the productivity boost those frameworks will provide.
Later, after some experience gain, maybe the meta programming aspect of Ruby will show some gain.
But at the first moment, it’ll not be so visible as you said.
Actually I’ve been debating with myself whether I should learn Ruby from ground up, thus allowing me to use RoR…….or, stick with Grails. I’m a J2EE guy by the way, but not a very technical guy (don’t ask me about performance of the JVM, I can’t answer you).
To me, it’s easier to move to Grails due to my knowledge of Java, but as far as I can see, it’s still not as popular as RoR. When it’s not as popular, the number of plugins will not be that much and also online help and articles will be pretty limited too. I did a search on Grails tutorial and there’s not much available. On the other hand, a search on RoR, and you’ll see tonnes of them.
This also points to one thing. With so many links/articles/sources, the demand for RoR skill is significantly higher than that of Grails.
Just my idea.
Oh, and I’ll most probably be moving to RoR. Just to learn up and have some fun. :)
@Alvin Lim, Hi Alvim (btw, you have a really nice blog). You know what? I think that everybody should learn Ruby. It´s a nice language, and if you´re a Java developer, it’ll simply blow your mind with new possibilities. So, it’s a great move in my opinion.
About the plugins, I’ll have to disagree with you. Actually: there’s a lot of them, and the number of new ones is growing really fast. Take a look at this link: http://grails.org/plugin/list#testing+tags
For me, the best thing about Grails is that it reuses all your legacy code (I know about JRuby) in a really transparent way. And you have to remember something really important: the biggest third party library of components and frameworks ever built, is the Java one. That’s a great point for me. Wich is the case (at least for me) to try JRuby when working with RoR (btw. Does RoR already works 100% with it?).
The jar problem you mention is already solved with Maven2’s fantastic dependency management.
Maven also provides you “scaffolding”-like features with it’s archetype (see AppFuse) framework.
Excessive amount of xml config files can be dismissed, when using a modern dependency injection framework, like Guice. Also annotations can be used instead of xml in the persistency config and other places.
Pingback: Why Grails really matters for Java developers | Jochen Toppe's Blog
I have never been more excited about writing Web Applications in Java again using Groovy on Grails. It has brought new energy around web development. It is hard to explain all the productivity gains it brings to the table in just these few lines of comments. I have tried a few frameworks from Struts to Tapestry to JSF etc… But the fact the Groovy on Grails leverages the concepts of Ruby on Rails and its built on Hibernate, Spring and Sitemesh and using the language and concepts which are simple but very powerful. Cut your lines of code by a huge amount. Plugin concept is fantastic. I wish Google App Engine supported it. TRY IT TO BELIEVE IT. YOU WILL NEVER LOOK BACK
I share the same opinion!
I share your enthusiasm about Grails. If you have the option to pick your framework, then Grails is a great choice. However quite often you don’t have the option to use Grails, and you need something that has similar goals to Grails. Skyway Builder is another open-source project that takes a different approach to Grails, but creates pure Spring MVC and Spring Web Flow applications.
I also found Java web development tiring with way too much work for wiring it all together. I am taking a look at ZK and without knowledge of Grails I think they fall in the same category of rapid application builders.
With ZK you can write components using Java (easy, simple coding) and these components can then with minimal configuration be used as tags to markup pages for the application, much the same as extending HTML with your own tags. ZK comes with a rich eclipse plugin that now boasts a visual editor window with sync to markup editor. ZK is a framework growing in popularity.
If anyone know of high level practical differences between ZK and Grails, I’m eager to hear.
I prefer to use Roma Meta Framework (http://www.romaframework.org). Has similar concepts of RoR and Grails but:
– It’s totally POJO based: supports full refactoring and easy debugging
– It’s really DDD
– Scripting is supported and choose what you want (Ruby, Groovy, Javascript, etc.) or mix them
– A lot of plug-ins already developed
Take a look and tell me what do you think about it.
Lvc@
@Lvc@ Just by coincidence, some days ago I was reading something about it (hey! You´re the creator, right?)!
By the way, congratulations for the great work!
“wich”?? “sintax”?? For such a visually effective blog, your spelling errors detract from this greatly.
@Fred. Sorry for that Fred. That’s because english is not my primary language, so this kind of spelling errors may happen.
But I hope they’ll reduce as I practice, ok?
I think grails will catch on once the IDE support for groovy catches up. I started trying to test my java code using groovy, but was slowed down too much by all the missing functionality. No quick fix and no refactoring support means no adoption.
http://www.netbeans.org/features/groovy/
I agree with almost everything that has been said about J2EE development. The only real problem I have with both Rails and Grails is that they are based on a dynamic language(Ruby/Groovy).
The problem is not Java – it is the frameworks around it. All the problems described in the post have to do with the frameworks, not really with Java.
Dynamic languages are great in the initial part of a project – the problems start in maintenance. As the code base increases in dynamic languages it is very difficult to do any kind of analysis and it becomes very difficult to figure out exactly how things fit together. I agree that with Rails it is a bit easier because of the structure of the Controllers and Views, but over time even Rails starts getting a bit much for Jr level programmers in offshore teams.
The main advantage of Java is that it catches a lot of simple the issues at compile time.
In my view the answer is not to move away from Java to Groovy but to fix the frameworks so they start understanding conventions and need less configuration.
Pramod: using Scala with Lift you get the best of both worlds: static type checking but the type inference and flexibility of dynamic languages. See Bill Venners blog
Hi Pramod (#13),
You state that:
“The only real problem I have with both Rails and Grails is that they are based on a dynamic language”.
And as a defence of your view you site:
“The main advantage of Java is that it catches a lot of simple the issues at compile time”. (sic).
You also warn that Dynamic programs are hard to maintain and won’t scale.
I would like to point out that although often repeated, the statements, are contended by by people who use dynamic languages, daily, to great effect.
Many find the rich built-in data-structures, the availability of a shell, duck typing, and the shear concision of some dynamic languages, leads to smaller codebases for equal functionality. With less code comes less errors and an easier maintenance task.
Java may well be great at handling large codebases, but have you ever thought that maybe the standard Java process of development *leads* to larger codebases?
There is nothing so frustrating as having an idea, but having to write ‘boilerplate’ code to satisfy the language for little or no gain. When writing in Python for example, I find that most of what I write is central to the algorithm, and guess what. Some of the extra stuff is their to make what I write more maintenance friendly, as easy maintenance is an important of the goal of the language designers.
If static typing is such a boon, (and I would emphasize the if), then surely having to write out the type of everything is a laborious and error-prone chore, especially when their are languages that have type inference schemes that can take much of that drudgery away from the programmer?
Their is a place for both static and dynamic languages and I think your comment amounts to FUD, as a task that employed a large number of Java developers is assailed by solutions coded in dynamic languages such as RoR in Ruby, and Django in Python.
– Paddy.
Hi Paddy,
As I said before – the problems I stated are what I have found in my experience working with offshore teams. Don’t get me wrong – I am not saying dynamic languages are bad. I have been on projects using Grails and used jython/perl/tcl extensively myself – and I love them.
My point is that when I work with Jr Level developers, specially when they keep changing – as it often happens in offshore teams – I find that code written in dynamic languages by Jr Level programmers gets very difficult to maintain because they do not take the care necessary to keep it clean.
And I don’t seem to be the only one who has noticed this. As “Alex Payne” of Twitter says in the interview http://www.artima.com/scalazine/articles/twitter_on_scala.html – “As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system”. As systems grow large statically typed languages allow all sorts of code analysis and refactoring tools to spring up.
I completely agree with your point about boilerplate code, but as both Rails and Grails have proved – generation is an option for boilerplate code and code generation can be language independent. And the whole point of my post was that Java is missing the right frameworks.
I don’t think my comment amounted to FUD – RoR, Django are new frameworks as Java was in the 90s, change is an integral part of the software industry so please do not be under the mistaken notion that Java Programmers cannot learn new languages/frameworks :). I have no issues using RoR, Grails, Django or the next one that comes along. And as a friend of mine says – The best thing that can happen to us consultants is for everyone to move to RoR & Grails because there will be a lot more work for Sr level people who can actually debug large systems written in dynamic languages :).
My apologies, I see where you are coming from now.
I’ll need time to think on why it is that junior programmers can be made to be more productive with static typing.
– Paddy.
Paddy, that’s because they understand project dynamics less and often don’t care about application life cycle and maintenance costs. At senior level your income is likely to be a function of your application stability in production and time it takes you to react to a change of business environment, it makes you think about quality of your code at all the times.
Ace website. You have brought in a recent reader. Please keep up the superb work and I look forward to more of your gripping updates.
Pingback: Why Groovy?