Thursday, July 05, 2007

5 More Misconceptions About Grails

Grailscommitter Marc Palmer posted a nice entry expressing 10 common misconceptions about Grails and what it is about.

This was linked to from another interesting post entitled Blasphemy: The case against Rails, which highlights the strength of Java and the how "Groovy/Grails is proving itself to be a formidable challenger".

An interesting aspect of the above post however, was the reaction of Ruby/Rails users to the outrageous comment that Grails is a more realistic alternative in the enterprise. Some of the comments including even more classic misconceptions and knee-jerk reactions which I will address in this post. My 5 misconceptions are a bit more long-winded than Marc's, but I think it is needed to address each one completely:

1) "Who needs Grails when we have JRuby on Rails?"

This is a classic and is the foundations for one of the biggest misconceptions about what Grails is. JRuby on Rails is an excellent way to run Rails apps on a Java EE container like GlassFish. End of story. Grails has very different goals. It is not a port of Rails to the Groovy language. It is the act of bringing together solid industrial strength components like Spring, Hibernate, Quartz, Compass, Sitemesh etc. and making them DRY by embracing convention-over-configuration.

We're not re-inventing the wheel and because the vast majority of the core of Grails is Java it is more robust and performant. Grails is actually a Spring MVC application at its core and is deployable onto all major containers, not just Glassfish, including the big commercial ones such as WebLogic, WebSphere and Oracle AS.

2) "Why use Groovy 'the half-way house' instead of just going for Ruby?"

This is another one that is often quoted all over the place. Why bother choosing Groovy when Ruby has the same features (some argue more)? Well this one misses the aims and goals of Groovy completely. Groovy IS NOT intended as a replacement for Java. Groovy (and Grails) are designed to be used symbiotically with Java.

Java is a great programming language for many general tasks, don't let the zealots persuade you otherwise. In the same sense Groovy is excellent at what its good at. For example Java is great for writing complex business logic or low-level plumbing code. Groovy is better at a higher level. Groovy and Java are meant to be used together.

This is starting to become more clear with the development of Groovy IDE support. The JetGroovy plug-in from IntelliJ allows you to have circular references between Groovy and Java code and ctrl-click navigate from Groovy classes/methods to Java and vicaversa. It is awesome stuff. Groovy developers use Groovy because we love Java, the language, the libraries and the platform.

3) "Why is Grails more suitable than Rails for the enterprise?"

A number of reasons. Two of the biggest ones are Spring & Hibernate. As it stands to day a enormous number of organisations are using Spring & Hibernate. They have existing Spring context, existing Hibernate domain models, and so on.

I was in this same situation before I started working in Grails. Grails is designed to integrate with these frameworks as seamlessly as possible. So for example you can drop a Hibernate domain model written in Java and mapping files into a Grails app and start using dynamic finders and GORM straight away.

In addition Grails controllers use standard ServletAPI objects like request, response, session etc. and can sit alongside other servlets. It is after all just a Spring MVC application under the covers. Rails on the other hand is designed almost in a way EJB2 was designed (shock, horror bear with me while I qualify this). In other words you extend framework objects like ActiveController, ActiveRecord etc. which bind you to the framework.

There is also no such thing as a domain model in Rails. Rails models are database tables. This is all well and good, but in enterprises the same domain model is often re-used in multiple applications both desktop and web. This is effectively accomplished in Java by packaging the classes with the mapping files in a JAR.

4) "Groovy/Grails are not a credible competitor to Ruby/Rails"

This one is entertaining. Often the credibility of Grails is questioned because it is newer and has a smaller userbase. However my view on this takes me back to the foundations of Grails. Grails is built on very credible technologies. This point was also addressed nicely in Marc's post.

The other area to consider is the arenas that are being competed in. Grails has two goals primary goals. The first goal is to create a web application framework that is easy, elegant and DRY without sacrificing the platform, technologies and tools on which the Java community is built on. A framework that is suitable for enterprise scenarios (see above). DHH was quite happy to dismiss the importance of the enterprise, we're not.

The second goal is to lower the barrier of entry for Java web development. Make Java web development as easy as Ruby/Rails development. Now these are generally conflicting goals, but on the whole we've done a pretty good job at meeting both requirements up until now. Whether Grails will receive more adoption in one man shops and small companies is up for debate, personally I see it being adopted more in larger organisations.

5) "Why bother with Groovy when Ruby is backed by Sun?"

Sun were kind enough to lend a hand to the JRuby project in their hour of need and should be applauded for doing so. However my standard answer to this one is the best things rarely come directly from Sun (Spring, Hibernate etc. etc.).

Well said. I am thoroughly enjoying my experience with Grails thus far with my "hobby" projects and look forward to bringing it to bear on some of our problems here at St. Jude. Given our heavy existing investment in Spring and Hibernate, Grails "just makes sense" for the move toward a more dynamic environment for us.

Good post, but I should mention that Rails models aren't necessarily tied to a database table. They are, after all, simply classes. The `models' as represented by those classes in the models directory that subclass ActiveRecord::Base are 1-to-1 representations of database tables, but more complex structures can be defined with non-table-backed classes that can be used with similar ease.

Nonetheless, as you said, the goals of the two projects are quite different, so running comparisons between them is only sometimes worth doing.

Just to make it clear, GRails is not better than JRuby on Rails at reusing the Spring context, here is an example:http://mysterycoder.blogspot.com/2007/06/include-spring.htmland keep in mind this is just the beginning...

GRails isn't better either to be deployed in legacy J2EE containers by the way. It just works with JRoR too. You only ear less abou JRoR being deployed on Weblogic or other legacy containers cause companies are slow in moving to JRuby and those containers aren't used by Open Source zealots. But Glassfish, Tomcat and Jetty are serving JRoR war webbapps like a charm. (and BTW, even in the web company I'm working, Smile.fr, we never advise to use containers such as Weblogic or Websphere, there is no benefit at all and much more bugs).

In my opinion, the only current advantage of GRail is Hibernate. That's true that Hibernate is way faster than ActiveRecord. Still, you could already use your Hibernate DAO layer within a JRuby on Rails app and I bet you won't wait that long before a better integration between Hibernate and JRuby on Rails is built.

Finally that's not entirely true GRails isn't reinventing the wheel: it's not reinventing the java libs, but it's surely reinventing a dynamic language while JRuby doesn't, just like JoR doesn't either force you to stay away from all the robust existing java libs.

Your post perfectly reflects misconceptions 2 and 3 and also shows clearly the naivety you have in terms of application servers.

Weblogic and Websphere might not be of benefit to you, but there are many enterprises who have these systems deployed.

As for Hibernate being the only benefit, this reflects misconception point 2. Sure if you're only going to write all your code in Ruby then fine. However if you are planning to have a mixed source system with Groovy and Java there is only one winner and its not JRoR.

Next week is my boyfriend birthday, I do not know choose what present for his birthday, my good friend tell me that you can buy the flyff penya do the present, because he was very like to play the Flyff, yes, this is a good idea, but I do not know how to buy flyff penya and where wo buy the flyff gold, so this is a different problem for me, so I hope know how to buy the cheap flyff penya can told me, in here I was very thank for you.