Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

RECENT ENTRIES


Tag Cloud


abbie appfuse birthday denver family grails gwt jack java javascript jsf linkedin maven montana roller skiing softwaresummit spring springmvc struts2 travel trish vacation webframeworks wicket
« Don Brown Makes... | Main | What a forecast! »
Wednesday January 30, 2008

Is there room for both Rails and Grails in a company?

For the last week, I've been knee deep learning more about Rails and Grails. The reason is because I think developers (and companies) are going to have a hard time deciding which framework is best for them. The real question is: do they both do the same thing or are their different applications for each? Is "Grails vs. JRuby on Rails" a "Struts 2 vs. Spring MVC vs. Stripes" argument - where they're all so similar it probably doesn't really matter which one you choose?

Of course, the Stripes folks will object, but I really don't think it's that much better than Spring MVC 2.5 or Struts 2.1. Sorry guys. ;-)

If it is a Spring MVC vs. Struts 2 type of argument, then it seems to make sense for a company to standardize on one -- don't you agree? Does it make sense to allow both frameworks in a company if they're so similar?

Google has had much success in restricting its allowed programming languages to C++, Java, Python, and JavaScript. Shouldn't other companies do something similar? It seems like a good idea to restrict allowed web frameworks to a few as well. For companies with successful Java infrastructures, it seems logic to allow one Java-based web framework and Rails or Grails for getting things done as fast as possible.

Here's the sticking point: Ask any Rails developers and they'll say Rails wins hands down. Ask any Grails developers and they'll say Grails is the easy choice because it builds on top of Java's strong open source projects. Blah, blah, blah - where's the objective voice that's identified the "sweet spot" for each?

The Relevance guys, particularly Stuart Halloway, has a post about How to pick a platform. The logic in this post seems to imply that both frameworks do solve the same problem - just in different ways. Stu seems to recommend Rails for most applications, because Ruby is a better language. He says Grails might win if you have "an established team of Spring ninjas".

I know Stu and believe he does know his stuff (in both Java and Ruby). So is this the definitive guide on which framework to choose? If you have a staff full of Java developers, they should start learning/using Rails rather than doing the easier transition to Groovy, which they pretty much already know?

I don't know what the answer is, but that's what everyone seems to be saying. The problems is, the authorities on this matter (Rails vs. Grails) are often "head honchos" in companies that have a vested interest in seeing their respective framework/platform succeed. Since the Relevance team employs some Grails developers, it seems they're less biased. But who knows.

Is Rails really head and shoulders better than Grails? I don't think so, but I've only been programming with both for a week.

Posted in Java at Jan 30 2008, 11:48:14 AM MST 11 Comments
Comments:

Does Grails really bring alot to the table if your developing against a legacy schema? IMHO, I wouldn't choose grails as a framework for anything other than a greenfield project. Struts2/Wicket/Tapestry/JSF seem to be a better fit. You don't get the RAD benefits of something like Rails but this is the nature of the beast when using a legacy schema....I'd rather use a presentation layer framework such as Tapestry than try to swim upstream in a Grails/Trails/Rails/Django architecture.

Posted by DanielHonig on January 30, 2008 at 01:13 PM MST #

Who cares about Rails? IMHO there is no use-case for rails except the easy (because unsecure and unstable) installation, where it might run easier on the LAMP stack. But why dump all the benefits of the JVM if you gain nothing from it. The dynamic capabilities are in grails/groovy even better than in rails/ruby. So for me it is a no brainer to go for grails. It enables you to start quick and dirty and evolve to more sophisticated solutions if needed. Ruby/Rails is a dead end road. Stop bothering about it.

Posted by Karsten Voges on January 30, 2008 at 02:32 PM MST #

I'm in the same boat as far as Grails is concerned, as I have only been developing with it for less than a week. But I have been developing Rails for about a year now, and thus far haven't encountered any stability issues in my production application environment. Furthermore, the development process of my Rails app has been and continues to be a much more pleasant one than the last WebSphere/Struts/Hibernate project I worked on.

But Rails as a framework starts to suffer when you take it out of its niche and start trying to make it work with legacy codebases and schemas. That's why Grails has piqued my interest - RAD goodness with the power of Spring and Hibernate hiding under the covers? That sounds like your classic "have your cake and eat it too" situation. If Grails offers a similar experience to Rails (which is a positive one), then Grails might just be a better mousetrap.

Posted by Kevin Whinnery on January 30, 2008 at 03:25 PM MST #

I was assigned a project to build rather quickly the two weeks ago. I am a Java developer and found that while rails was great I needed to System Admin to get a test application going since to install a GEM was requiring access to /usr/local. I was a bit miffed by it and downloaded grails

ran grails create-app, created domain classes and was up and running without even needing a database since HSQLDB is set up to go by default. After 2 days with rails I switched to Grails and felt a WHOLE lot more comfortable. No need to futz about with SQL statements creating tables first etc. Just define classes and you're off No real need for RAILS going forward for my needs There basically isn't anything that RAILS does that GRAILS does not do.

As for the legacy application support I am not sure what exactly you are referring to because Grails handles Legacy just fine so please put the FUD Porridge gun down. Grails works just fine and is great if you are already working with Java. I dont see what the problem is Download them both and test out for yourself you will see that Grails has come out as good as rails if not better since it learned from Django, Raiils and turboGears etc...

Posted by SM on January 30, 2008 at 03:45 PM MST #

You aren't going to convince an exec to throw away his investment in java appservers to go to native Ruby. So it needs to run in the JVM. Grails builds on top of java while JRuby is something that is shoehorned into the JVM.

Posted by 71.75.148.242 on January 30, 2008 at 04:14 PM MST #

As far as legacy schemas go, if you need the RAD-speed of Rails in Grails, you can use Hibernate Generator Tools to generate JPA domain classes and use them with minimal Hibernate configuration effort (linking to the package.class.name) as your Grails domain classes. Thats probably not the best way to do things (code quality), but the speed of Rails was the thing in question here. There you have it. Legacy schemas just as fast as with Rails. Plus no downside risk of ActiveRecord yet all the power of Hibernate.

Posted by Sakuraba on January 30, 2008 at 04:27 PM MST #

For legacy schemas Grails offers it's GORM DSL which makes it a breeze to map your domain classes to legacy tables. For legacy application integration we are using Spring to integrate our Grails app with an existing EJB server.

We have no Spring or Hibernate "ninjas" here but any Java EE developer will be able to get up and running with Grails pretty quickly, as I'm sure Matt will see as he continues his investigation.

Posted by Dave Klein on January 30, 2008 at 04:51 PM MST #

I'm actually playing with both as well. I'm a Java developer which is my "Bread and Butter" language - but I really like ruby. I hear this all the time - and I think it's true as well - but Ruby does seem more "elegant" than groovy. It's hard to explain - it's like using a Mac compared to a PC to me. It just feels cool. Now I've never done a ruby on rails app though - that's something I am going to try on my spare time. Just my 2 rupees.

Posted by John Mark on January 30, 2008 at 08:54 PM MST #

One way to protect your Java investment and enjoy the power of Ruby and Rails will be to go for JRuby. In one of our recent projects, we developed a module in JRuby and Rails and could nicely integrate with the main Java application.

Posted by Debasish Ghosh on January 30, 2008 at 10:49 PM MST #

They both work fine. I think Grails is a more complex system than Rails, since it is dependent on other huge projects (spring, hibernate, servlets) for it's capabilities. The Rails stack flows together naturally, while the the Grails stack is a really clever layer over top of the other stuff. That said- one of my favorite Ruby libraries, Builder, is a copy of the XML building technique of Groovy.

Overall- Ruby core libraries are more full featured than than Groovy or Java, and the Rails extensions result in a very intuitive way of building applications. In many cases, I am able to sit down with a business user in front of one of the large Rails applications I work on and actually have her watch and understand most of the code I am writing to implement a feature she wants. Very cool.

I still see room for a simpler Java framework- something with Servlets as controllers, ActiveRecord equivalent for models and something like GSP for views?

Posted by matt m on January 30, 2008 at 11:36 PM MST #

Hi Matt. I didn't say this explicitly in the article you link to, but I definitely think there is room for both Rails and Grails in an organization. And either one is light years better than neither. I have a new post that I hope is more clear.

Posted by Stuart Halloway on February 04, 2008 at 12:06 PM MST #

Post a Comment:
  • HTML Syntax: Allowed