20080307 Friday March 07, 2008

Grails vs. Rails - My Thoughts In a comment, Jared Peterson asked:

I'm curious if you have any thoughts on folks that might be trying to make a decision between Rails and Grails. I like the concept of "Allow Both", but what if you "have neither"?

If you were starting a new project, could choose either one, needed to interact with a lot of existing Java code (JRuby on Rails I guess), what would you pick?

A friend recently asked me "Can I solicit your honest, unadulterated opinion on Grails?" I think the e-mail I sent him may help Jared's question.

I think it's awesome. IMO, it's the same thing as AppFuse, but it has a DSL that's much simpler to learn and remember. Less code -> faster productivity. There does seem to be some maturity issues, but I think it'll get there. The question is - how fast can Groovy become. It's similar to Rails and Ruby in that you start using Grails and you think "This Groovy thing is kinda cool, I'd like to learn more." One of the reasons I really like it is the learning curve for experienced open source Java Developers is virtually flat. You can learn enough to be productive in a single day.

That being said, I think there's also a lot of cool stuff going on with RIA. IMO, Flex or GWT + Grails would be a really fun set of tools to develop with. Here's a excerpt from a write-up I recently did when analyzing Rails and Grails at LinkedIn (in January):

--------
Comparing Rails and Grails
They're both excellent frameworks. Rails is definitely more mature, but the environment is a pain to setup (esp. on Windows). Grails is very easy to setup for Java Developers. Grails needs a lot of improvement as far as hot deploy and stack traces. It's probably Groovy's fault, but its stack traces are hideous - rarely pointing to the class and line number in the first few lines.

As for hot deploy, it doesn't work nearly as well as it does with Rails. Rails' "script/server" starts WEBrick in a few seconds, while "grails run-app" can take up to 10 seconds (even on a brand new application). Even with its warts, Grails is simply awesome. I really, really enjoy writing Groovy code in IDEA and seeing immediate changes. I don't like "test-app" as much as I like Rails' "test:units" (or even better, "test:uncommitted"). It seems to be widely realized that Rails has a better testing story.

Rails is immediate, Grails is immediate 70% of the time.

Groovy is extremely easy to learn for Java Developers. Ruby is easy too learn, and possibly too powerful for OO rookies. Both are fun to program in and very capable of allowing greater developer productivity. If you know Hibernate, Spring, SiteMesh and JSP, you owe it to yourself to look at Grails. If you know these technologies well, you can learn Grails in less than an hour. You can be productive in the next hour and have an application running by the end of the day. That's not to take anything away from Ruby. I believe that Rails is an excellent platform as well. It's pretty cool that profiling and benchmarking are built into the framework and you can easily judge how many servers you'll need to scale.

I used IDEA while developing with both frameworks. IDEA has Rails and Groovy support available via plugins and they both worked quite well. The support for Grails was much better than Rails. Grails offers code completion, Ctrl+click on classes/methods, debugging and starting/ stopping the webapp from your IDE. Rails doesn't offer much in the way of Ctrl+clicking on class names/methods or debugging.
--------

Is there anything that Rails can do that Grails can't? Not as far as I can tell. I think it really comes down to developer passion and team preference. If you have experienced Java Developers that like the ecosystem and its tools, Grails makes a lot of sense. If you have experienced PHP developers or frustrated J2EE developers, they might enjoy Rails more. One thing that's very cool about both frameworks - learning one actually teaches you things about the other. They're so similar in many respects that knowledge is transferable between the two.

Of course, this is all just my opinion after working with both frameworks for a few weeks. For anyone who has tried both, what do you think?

In closing, here's an excerpt from a recent comment I left on Javalobby:

Of course, the hard part now is deciding between Django, Rails, Grails and GWT for your web framework. Then again, that's like having to choose between a Ferrari, Porsche, Lamborghini and a Maserati. No matter which one you choose, it's unlikely you'll be disappointed.

Posted in Java at Mar 07 2008, 05:12:00 AM MST 11 Comments

Comments:

Why "frustrated J2EE developers" might enjoy RoR more comapred to Grails. I guess question is not answered clearly for Java developers.

Why can't you assert Grails is better compared to Rails for java developers?

For new projects (without any java legacy code) what could be best choice.

For new people (With no prior experience java,PHP,Ruby), which one you prefer or suggest.

I guess answer can be either Grails or Rails for above questions.

Posted by Praveen on March 07, 2008 at 07:03 AM MST #

Most of my day to day work is in PHP I have to say, personally at least, I find grails much nicer to work with than Ruby.

The biggest boon for Grails over Rails is the ability to mix and match Java code. That means access to a highly performant fully featured ORM like hibernate. ActiveRecord IMO doesn't come close.

Posted by Aaron Bonner on March 07, 2008 at 08:24 AM MST #

Just a footnote that if a company has a number of legacy Struts 1 apps and is considering the jump to Rails vs Grails, a Struts 1 plugin for Grails was recently released:

http://docs.codehaus.org/display/GRAILS/Struts+1+Plugin

It literally allows you to drop all of your existing Java Struts 1 code and xml confiig right into a Grails project, fire it up, and start mixing and matching Struts with Groovy (e.g. Java Struts actions rendering via GSPs, Struts actions written as Grails controllers, etc.).

It's obviously pretty new, so there's bound to be some issue with it. But this seems like a perfect way to break out of the Struts 1 handcuffs for a lot of companies.

Posted by Jim LoVerde on March 07, 2008 at 09:46 AM MST #

One thing I can add is that the instantaneous nature of rails goes away as soon as you invite JRuby to the party. Running tests or firing up the server in rails when using native ruby is awesomely fast... but when you do it with jruby instead, you have to incur the cost of the jvm starting up. It's probably not something I would've noticed had I started with JRuby on Rails... but getting used to pure ruby on rails and then switching to something slower is a bit of a drag.

Also, we tried deploying a rails app as a war with JRuby 1.0 and it basically shit the bed in terms of scaling. For all I know, it could've worked much better with the right configuration, but IMO, it ought to have scaled much much better than it did out of the box. I know JRuby has made good progress since 1.0, but that initial experience soured me.

If you're seriously considering a JRuby/Rails deployment to Tomcat type of setup, I'd be on the lookout for good white papers or case studies about how someone got it to work and scale well for them... that, or use it on a project that's not high pressure or doesn't expect a ton of load to prototype with in the first place. I'm not saying it can't be done, I am saying it's not nearly as easy and ubiquitous as a typical java webapp in this regard.

Posted by Bryan Noll on March 07, 2008 at 10:19 AM MST #

I, too, am very interested in the Grails vs. Rails evaluation. Like the commenter, I haven't started development in either, so I could go either way.

Despite my experience with Java, Spring, and Hibernate, I'm a little concerned about the main selling point I keep hearing over and over in favor of Grails: "leverage existing Java skills." That's a fine point for companies with established development teams, but as a freelance developer I'm not afraid of learning something new and I don't have a team of developers that need to be retrained. Sometimes I think it almost comes across as "We old Java farts can't keep up with the kids these days and their new-fangled Rails and whatnot!" :)

The main advantage I see in Grails at this time is the world of Java libraries that have been developed over the years that can be used to accomplish all sorts of tasks. At one time, I was also thinking that Grails would be significantly faster since it runs on a highly optimized JVM, but now that I've seen a Groovy stack trace, I'm not so sure. I should code some benchmarks one of these days.

After hacking on a Python webapp the other day, and seeing how it started up seemingly instantaneously, compared to my Spring MVC app that takes about ten seconds, I do have to admit to having some startup time envy. :)

Posted by David Simmons on March 07, 2008 at 10:54 AM MST #

Thanks for the post, this is great. I'll keep you updated as we make decisions in the future. We plan on evaluating both as a team pretty soon.

Posted by Jared Peterson on March 07, 2008 at 07:14 PM MST #

I like the way your analysis has been shaping on this question. I think your statement that "Ruby is easy too learn, and possibly too powerful for OO rookies," is pretty ridiculous though. Books like Pine's "Learn to Program" can gently get people into Ruby. In fact, I think the bigger problem with learning a pure OO language like Ruby before learning Java is the learner will be extremely confused with all of the gesturing and complexity that has to be done in Java to make simple things work. Going back to Java from working on Rails projects for the past two years- it's just painful to see how much code really does nothing for the user. Anyway- shouldn't you be comparing Groovy and Ruby in terms of learning?

That said- I totally agree with the JRuby and other comments above. Comparing the instantaneous feedback of developing on Mongrel with waiting for the app to reploy on our current app server of forced non-choice- ugh. I used to go through that cycle of making a change and then peeking at the app in Rails at least 50-200 times per day. I simply can't do that as often in Java- the cost is too great. As a weird side effect, I find my Rails applications have far fewer bugs than any other code I've ever written. It was not unusual for us to release an increment with zero defects, and that hasn't happened yet for me with a Java web app, despite 7 years of trying.

Posted by MattMc on March 08, 2008 at 10:56 PM MST #

RE: "Rails is definitely more mature, but the environment is a pain to setup (esp. on Windows)."

How is it a pain on Windows? While it's true that I'd never want to run a production Rails app on Windows for performance reasons, setting up a development environment is as simple as running the one-click installer found here:

http://rubyforge.org/frs/?group_id=167

After that, it's pretty much exactly the same as every other ruby installation. RubyGems is installed exactly the same way. Individual gems are installed exactly the same way (mongrel, rails etc.).

I think the biggest issue is just performance. Ruby is sloooooow on Windows.

Cheers,
Clinton

Posted by Clinton Begin on March 10, 2008 at 08:02 AM MDT #

One of my main concerns with JRuby on Rails (NOT Ruby on Rails, mind you; there's a whole other set of concerns there...) is the fact that Rails development is completely oriented towards single-threaded development; that clashes directly with most of the assumptions made by a Java Servlet engine. Rails users expect that no concurrency issues will occur, and that most of them can be fixed by either using sticky sessions or relying on the DB to handle concurrency. Java puts concurrency issues right there for the developer to handle. Both models have their strengths and weaknesses, BUT you simply can't take Rails, slap it on Tomcat, and expect that magically all concurrency issues will disappear. I'd rather use a framework which is more comfortable with a Java environment, such as Grails, if I'm going to deploy to a Java EE container...

Posted by DR on May 08, 2008 at 01:00 PM MDT #

I am a java web appliation developer using mostly JSF and J2EE. I havent worked with JRuby on rails yet but I can share my experiences with both the frameworks. I started working with rails last year and I think its simply awesome but I got bogged down by capistrano and the general deployment of rails and found myself looking up the internet way to often for simple things like drawing graphs, messaging, crypto etc.

But grails takes the comfort level to a whole new dimension. Firstly at the guts of the framework are spring and hibernate. Which means you get DI, integration with frameworks like acegi and one of the most mature ORM layers out there. I also think integration with quartz for scheduling is fantastic news (I cant seem to think of a comparable scheduling framework for rails).

For any java developer who has worked with spring grails is great news. You will find that you can make use of all the libraries out there, use features like remoting, easy threading and pooling, messaging and declarative security - all together with scaffolding and GORM giving you best of both worlds.

Also I think groovy is a fantastically productive language (I am sure other people feel the same way about ruby), but the fact that you can use java annotations, transparently implement interfaces by java coercion and compile back to vanilla byte code is all great news and gives grails an edge in my opinion.

Posted by pranay ahlawat on June 03, 2008 at 06:16 PM MDT #

WebObjects is king of the hill. What's new I suppose...

Combined with WOLips+Eclipse, ProjectWONDER and the WireHose framework enhancements, these other "frameworks" look like a Win 2.0 era joke. Of course any other Java code can be re-used too.

Some people may not like it. Others just ignore it, talk and argue about all the other inferior sh!te that they move between every couple of years. Doesn't change the actual reality that WO exists and powers two massive Internet apps, the iTunes store and Apple store.

NeXT brought UNIX and object-oriented frameworks to the masses. You should learn from the proven experts.

Posted by John C on June 07, 2008 at 12:17 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed
Click me to subscribe
Matt Raible is the Lead UI Architect at LinkedIn. The opinions on this site are mine, not my employers.
« August 2008
SunMonTueWedThuFriSat
     
1
2
3
4
6
7
8
9
11
12
13
14
15
16
17
18
19
20
22
23
24
26
27
28
29
30
31
      
Today

Recent Entries

Tag Cloud