Grails vs. Rails - My Thoughts
In a recent comment on my blog, 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 recently left here 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.
- Login or register to post comments
- 7025 reads
- Flag as offensive
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Raphael Valyi replied on Fri, 2008/03/07 - 9:12am
"Is there anything that Rails can do that Grails can't?"
-> Well, I'm not a specialist of Grails, but I think the resource stuff of Rails is more powerful. I think Rails is more powerfull at:
Overall, this makes code simple to wrtite, read and maintain, and easily Restfuly interoperable, leveraging all the HTTP caching goodeness instead of non scalable webservices.
BTW, You shouldn't think native Rails anymore. You should now think JRuby on Rails. This is now more performant, simpler to deploy (yes, this is finally true!) and allows you to access all the Java platform power, much like Groovy. Also the Rails maturity shouldn't be neglected: Rails does have A LOT of very useful plugins for free, much more than Grails currently (and in JRuby you can also leverage java frameworks the same way). Some useful plugins include: globalize for localization, resful URL mapping for Globalize, resftful authentication, openid authentication, act_as_state_machine for easy unbloated BPM, act_as_taggable, acts_as_ratable and much much more. With Rails, somebody always found a 1 liner to any problem you are likely to encounter and this has a lot of value.
By the way, with native closures inside Java7, I see the space of Groovy threatened, so I'm not too sure it's such a strategic move on the medium and long run.
Have fun.
Raphaël Valyi.
Graeme Rocher replied on Fri, 2008/03/07 - 9:54am
in response to: raphael valyi
"Is there anything that Rails can do that Grails can't?"
-> Well, I'm not a specialist of Grails, but I think the resource stuff of Rails is more powerful. I think Rails is more powerfull at:
Grails has a URL mappings DSL. I'm no Rails expert, but our users enjoy it
http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4%20URL%20Mappings
BTW, You shouldn't think native Rails anymore. You should now think JRuby on Rails. This is now more performant, simpler to deploy (yes, this is finally true!) and allows you to access all the Java platform power, much like Groovy.
Really? I wish JRuby people would get real about this. Without annotations, generics and a joint compiler you simply can't access the full power of the Java platform. Want to a write an EJB entity in Ruby? bad luck. Want to write a JSR 172 web service? too bad. In addition, its a one way contract, calling Ruby code from Java is not fun.
Some useful plugins include: globalize for localization, resful URL mapping for Globalize, resftful authentication, openid authentication, act_as_state_machine for easy unbloated BPM, act_as_taggable, acts_as_ratable and much much more. With Rails, somebody always found a 1 liner to any problem you are likely to encounter and this has a lot of value.
Grails has many plugins too, they're just different and more useful for the Java developer integrating it with Java technologies like GWT, Flex, RMI, JMS etc. :-)
Most of the Rails plugins benefit Ruby devs which is great, but the plugin community for JRuby is very young with goldspike being about the only one
By the way, with native closures inside Java7, I see the space of Groovy threatened, so I'm not too sure it's such a strategic move on the medium and long run.
Groovy's value extends far beyond just closures due to its dynamic nature, I think the only one that feels threatened is those, like yourself, who are realising Rails is not the only game in town ;-)
Sidewinder replied on Fri, 2008/03/07 - 11:12am
I will say Groovy and Grails is better for Java developers, I created a CRUD app in 10 min with Grails and I like the approach of Grails that everything start from the Domain. With Rails it was more effort for me, I checked the documentation twice and watched the screens on their website, Plus Ruby yes is easy language to learn but it syntax it is little bit alien to Java developers, Groovy is very close to Java syntax and powerful as Ruby.
Java 7 with closures will have it place and Groovy will have it place too. I use Java for long term and planned projects and I use Groovy for short term and without planning projects easy and fast to prototype or develop.
Raphael Valyi replied on Fri, 2008/03/07 - 1:33pm
Thanks for pointing out the Grails documentation (unlike with Rails I couldn't Google for it effectively). Still, now I'm sure about it: what the Groovy docs describes here is the Rails system back to 2004, not the Rails 2.0 nested resful resources of Rails 2007:
http://api.rubyonrails.org/classes/ActionController/Resources.html
And yes it does indeed mattern, Rails 2.0 isn't a small thing. Not fundamental, but still. In my app I might use a few dozens of such different URL patterns, but that's only 8 lines of code in my route.rb. I know it would have been some dozens of lines (of Ruby terse code) before Rals 2.0.
And that 's not only about those few saved lines. It's just one more evidence there are the leaders and there are the followers. Which one do you ambition to be?
Well point taken. IMHO that's the only conjonctural advantage of Groovy by now (aside from the syntactic proxmimity but personnaly I think learing Ruby is just worth the reward). Still, this is moving quickly: we had Rubinline (embedding pure Java code in Ruby) working yesterday and we will get a (J)Ruby to pure Java code compiler soon too. Not sure how far it can goes with annotations for instance but still I think it can goes far enough, with optional Java typying passed from Ruby back to Java. Not too bad...
OK, even if JRuby gets closer here, Groovy will stay a bit ahead regarding to calling the scripting language from pure Java code. But actually, the thing is that Ruby is so sweet that you are much more likely to do the contrary and feel happy with it: glue existing Java frameworks and do your abstracted domain specific code in the Ruby language. And BTW the Java 6 scripting framework makes doing the contrary okay too.
And finally no, I don't feel threatened at all, I'm only a happy JRuby part timer, I didn't invest anything big on such a language (unlike you), so that's all fine. I'm just writing this to save a bit of people time if they can give a shoot to JRuby on Rails instead of experimenting with Groovy. I doubt they come back to Groovy but one never knows, history will tells us.
Regards,
Raphaël Valyi.
Mike P replied on Fri, 2008/03/07 - 2:29pm
Graeme Rocher replied on Fri, 2008/03/07 - 3:05pm
in response to: raphael valyi
Oh we've done plenty of leading of our own. Just in a different direction. Grails features declarative transactions, rich conversations with web flow, command objects, tag libraries, built-in i18n all features conspicuously missing from Rails.
Some cross pollination *shock horror* has even occured ;-)
http://blog.thinkrelevance.com/2008/1/18/announcing-simpleservices
We just have a different focus than Rails, as you can see we plan integration with Java technologies like JPA, JCR, Portlets etc.
http://grails.org/Roadmap
Graeme Rocher replied on Fri, 2008/03/07 - 3:07pm
in response to: okidoky
I don't think in a post comparing Grails and Rails that you should be mentioning performance. Ruby's performance is nothing to shout about.
As for Groovy's performance the focus of the 1.6 release is on performance and there is already a measurable difference in SVN head.
Mike P replied on Fri, 2008/03/07 - 4:24pm
in response to: gr34134
But Groovy is trying to be appealing to the Java crowd. Groovy's fundemental dynamic nature deteriorates performance too much for serious development IMO. Every primitive operation results in wrappers and math method calls. Every method call results in introspection. Unless the Groovy runtime is re-invented Java will be a better choice for serious development I think. Upcoming closures and what-nots will deminish Groovy's appeal as well.
I'm not against Groovy, there is a lot I like. But if we want to see Groovy succeed, a concrete plan needs to be in place beyond tinkering and smoothening. A whole new parser/compiler strategy is needed.
End of day, we must NOT continue to see method calls where inline is possible, NOT see autoboxing where not needed (perhaps that requires updating the language spec), and NOT do indirect dynamic calls (with introspection) where the programmers clearly wants a plain straight forward method call. I certainly am not going to invest inventing technologies writting in Groovy knowing my inventions will be hampered by this.
Perhaps there is a plan, but is it the right plan?
Graeme Rocher replied on Fri, 2008/03/07 - 5:10pm
in response to: okidoky
Our plan is to get Groovy's speed on par with some of the fastest dynamic languages like C Python, but at the end of the day I think you are thinking about it the wrong way.
Quite simply its about picking the right tool for the job, Groovy is fantastic for what we use it for in Grails (a higher level wrapper around Spring/Hibernate etc.) the low level heavy lifting is done in Java. If you have really performance intensive code then you can always write that bit in Java. And because of the seamless integration between Groovy and Java this is trivial to do.
One of the worse things you can do in software development is optimise early, if and when you do need to optimise you are safe in the knowledge that you have 2 languages (Groovy and Java) that can interoperate seamlessly. Of course you would never write a 3d engine, or a game or heavily maths intensive programs in Groovy, its just no the right tool in this case the great thing is you have a choice :-)
zqu replied on Fri, 2008/03/07 - 9:50pm
You're complaining about a 10seconds server startup time ?
My server (inside the IDE) usually took 3-4 minutes to start (and I had to stop-start 20 times a day on an average coding day). Why ? Because :
The interdependencies between modules was sooo tighly coupled we couldn't break it apart into separete CruiseControl builds without major rework.
Graeme Rocher replied on Sat, 2008/03/08 - 3:49am
in response to: zqudlyba
phil swenson replied on Sat, 2008/03/08 - 11:15am
One of the cool things that rails has are migrations. When you make schema changes you update a ruby file with each change, example for table (projects,adding column "updated_at"):
class AddUpdateToProjects < ActiveRecord::Migration
def self.up
add_column :projects, :updated_at, :datetime
end
def self.down
drop_column :projects, :updated_at
end
end
Then you run a rake target (rake db:migrate) and it updates your table and keeps track of your current version in a database table.
Does Grails offer this? Are there plans to offer this?
Graeme Rocher replied on Sat, 2008/03/08 - 11:30am
in response to: philswenson
Mike P replied on Sat, 2008/03/08 - 1:30pm
in response to: gr34134
I think a better answer though, is to strive to optimize these things and perhaps make small changes to the language that makes it better possible to achieve these optimizations. Perhaps more redesign than optimizing.
The often commonly used stock answer is to use the right tool for the right job. The moment a Groovy application gets used under load and used beyond the simple test and hello world shopping cart toys, the system will buckle. Writing template processing engines and database processing engines might seem attractive in Groovy from a programming point of view, but in practice you just can't. For Groovy to gain real ground, I think it must tackle this issue. I think it IS possible to address the performance (beyond just streamlining and gaining a few percentages here and there). If the compiler knows, or even at runtime it knows, that a method call is known where it lands, it could generate code (at compile time and/or runtime) that allows it to call it without any instrospection. There is also no reason that if the compiler knows it's dealing with all typed variables that all the code can be inline without autoboxing or method calling for math operations.
Without tackling this, Groovy is positioned to compete with languages like Ruby, Python, and Javascript and the like. It's main competitor will be Java. This is really backwards, trying to appeal to Java programmers while in the end it'd be better to switch from Groovy to Java because it's the better alternative, because Groovy can't meet the requirements. Also, Ruby and Python remain rogue geeky languages that the industry is not willing to invest in and use for obvious reasons. Groovy just makes it another one of those. Groovy tries to sell the story that it is everything Java is and more. "There is no learning curve, it's just picking up where you left off and move beyond." Yeah, with one major thing taken out, all the advantage points of the Java performance. Now ok, granted, and this is cool, you can intermix Java and Groovy. But when is it ok to write what parts in Groovy, where every time you do, you risk making a compromise? Imagine in a project with a team of programmers in a weekly meeting. "Why is our server performing so badly?". "Oh, it must be Mr Soandso that keeps adding all these Groovy classes.". Perhaps not fair, but you see my point.
I really think the Groovy team should strive for a re-implementation. You can not afford to in the long run I think. I'd like to see Groovy succeed. How is this project run anyway? Is it a collection of volunteers, or is this an actual team of staff members at a company (Sun?). Or a combination of both?
Graeme Rocher replied on Sat, 2008/03/08 - 3:03pm
in response to: okidoky
Mike, I think you are imagining a different language. If your problem is that Groovy is a dynamic language and that it should be re-implemented as a static one then that is likely never to happen in the same way it will never happen to Python, Ruby or Perl.
There are many million lines of production code written in languages like Python, Perl, PHP and Ruby and they all are known to be able to scale to the demands thrown at them. Java developers need to get over the mentality that only code written in Java can scale, its simply fictional. Sure you'll run into bottlenecks and there are various ways to optimise those, but that happens in any language.
As for how the project is run, the main company behind it is G2One (http://www.g2one.com) for which I am CTO, we employ several people behind both Groovy and Grails including Guillaume (Groovy project lead) and Jochen (Groovy tech lead) full time on the project. In addition, there is of course, as an open source project, a large amount of contribution from volunteers and the community
ryan headley replied on Mon, 2008/03/10 - 8:59am
I've used both Rails and Grails and truly enjoy either. I'm finding the same things that are "curves" for me on one are that same things that are curves for me in the other.
Also, Graeme is right...its about choosing the best tool for the job. If you're wanting to integrate with EJB3, use annotation etc, the Groovy probably makes sense. Depending on your team as well, if they're already a bunch of Java guys and they're happy doing the Java thing, then you have to look at Groovy.
If you happen to be lucky and work in a place that will let their developers spread out just a bit on other projects, (usually internal projects) then it would behoove one to learn Ruby and RoR. The options are there to at least deploy along side your already existing java apps and architecture.
It took some time to get used to, but I like looking at Ruby code, it feels clean. Groovy code to me feels a bit congealed at times, but again, I'm getting used to that too.
I really do like the Grails domain model approach with the DB being built off the properties of your object and not the other way around.
Both are viable options in my opinion. They have similar weaknesses and similar strengths. I don't understand the purpose of the back and forth game when it comes to this. Chances are that unless you are running your own show or are the man in charge etc, you don't get to make these decisions. Alot of corporations say things like, we're all .Net, or we're all Java etc and you won't get the option to choose.
either way, you can't go wrong with at least familiarizing yourself with both. I'm sitting on a project right now where we basically have come up with three options: Grails, Rails or PHP+Code Igniter. (My preference is actually the PHP+Code Igniter) but due to some theoretical issues with the possible integration (it hasn't been decided on yet how heavily we'll be interacting with the other systems) we're looking closer at Grails and then Rails (in order to let our developers expand their horizons a bit).
In the end...you can get the job done with nearly anything...
Clinton Begin replied on Mon, 2008/03/10 - 9:16am
Graeme Rocher replied on Mon, 2008/03/10 - 9:30am
in response to: cbegin
Mike P replied on Mon, 2008/03/10 - 10:58am
in response to: gr34134
How about generating code at runtime that's compiled based on the types used. Everytime before running a method, it could check to see what objects are used and see if there's already a compiled version for it.
I really think it is possible to gain some serious performance with runtime compilation (which can be cached of course), without losing the dynamic aspects of Groovy.
Again, I'm hoping to see Groovy succeed. But as it stands I can't use it for anything serious. I might if I knew there is a concrete plan to address performance other than what you might still achieve with some tinkering.
Graeme Rocher replied on Mon, 2008/03/10 - 11:17am
in response to: okidoky
Hi Mike, there are various techniques that can be used to greatly improve performance, in Groovy 1.6 which will be out soon we're implementing the first cut at call site caching (see http://blogs.sun.com/jrose/entry/anatomy_of_a_call_site)
Which is a technique that allows the JVM JIT to inline code at a given call site if it can predict the path is said code is always going to be the same. We've seen that this technique has boosted Groovy 1.6's performance so that on certain benchmarks it is even 8x faster than Groovy 1.5
This is only the tip of the iceburg. My point is that we do don't believe that performance is going to be addressed by "just some tinkering" and have various strategies to resolve/improve performance in coming releases.
Mike P replied on Mon, 2008/03/10 - 1:07pm
in response to: gr34134
Ok, that almost answers my question. The first part, you're relying on the VM (they want us to remove the J ;-) ) to make methods inline. The second part agrees with me that tinkering will not get the performance we need. Thus there has to be a plan that provides a more drastic approach, which you indicate there is. Which is great.
I'm curious as to what the goals are and if the Java community can expect Groovy code to performance exactly the same as Java if the Groovy code is written a certain way (providing types I guess, or perhaps runtime compilation).
Sorry to keep hammering at this, but things are becoming more hopeful to me knowing a major item on the wish list is to bring performance in line with Java where possible. Do that, and Groovy will totally kick ass.
ps. I want to add that I didn't intend to take any wind out of your sail, making it seem that Groovy isn't worth it until I (we all) get what we want. I can definitely see many uses for it already. Keep up the good work !
darryl west replied on Tue, 2008/03/11 - 7:39pm
After spending two+ years developing in Rails I have happily now moved to Grails. To be fair, my prior development experience includes 10+ years in java, so the move to groovy was a natural.
Last week we released our first grails project to beta and a smaller project implemented straight groovy/groovlets. Thanks to the years of web container development that produced tomcat, jetty, resin, glassfish, etc., deployment was much easier (and safer) than with Rails/Mongrel (serous rails projects haven't used Webrick since 2006).
The combination of Rails, ActiveRecord and Ruby provide a great web framework. Grails, with the help of Spring, Hibernate, Groovy, and the best parts of the Rails framework provide todays best combination for serious web development.