Related
Yes, several similar threads exist, but we're now in 2011, and much has changed.
Grails 1.3.6 has improved hugely compared to v1.3 when I initially tried to learn the framework (and gave up to slow compile times and other groan inducing events).
Having spent a couple months with the latest release, I am impressed, protyping an app is an absolute breeze (GORM is great!). In development mode one no longer needs to restart, barring changes to domain classes. Groovy.lang is fantastic (bare in mind, this is compared to my day job life in PHP).
Now, on the flip side there is Ruby/Rails, which I have little experience with beyond perusing Ruby docs and exploring Active Record (to compare to GORM). Coming from PHP/Jquery, groovy syntax is cake, ruby not so much, although accessible.
Ruby/Rails is all the rage, while Groovy/Grails seems to be picking up speed in its own right.
I'd like to hear what both camps have to say (flame inducing lang war welcome) re: pros/cons of both langs/frameworks now in 2011. When choosing a framework it's important to know what you're getting into, so have at it, newbies will benefit, and experts can vent ;--)
Rails and Grails are both excellent frameworks with their current releases. You really can't go wrong with either. Here are some things I find interesting about them though:
Rails
Rails (Ruby) does not scale as well as Grails (Groovy). You will need more horsepower to run your application. This isn't a big deal at all with PaaS options like EngineYard (and hopefully a AWS BeanStalk Rails option in the future), but it might just cost a little more to run a Rails app vs a Grails app (obviously JRuby is also an option to though).
Rails is slightly better with NoSQL alternatives currently, but Grails is catching up quickly
Rails has many more plugins, but this can lead to trouble if you use some that aren't maintained (a lot of them don't currently work with Rails 3 yet either).
Rails is more mature and has more features at this point in time because it's been around longer
Rails REST support is amazing
There are many more "big" Rails websites than Grails
Ruby is much more popular than Groovy - TIOBE
No dependence on Oracle, ha! (Grails obviously needs the JVM)
Grails
Grails integrates with the JVM better than JRuby
Grails GORM is better than ActiveRecord (IMHO), although Rails 3 opened the door a little bit for other persistence options, but all the books, tutorials, etc all use ActiveRecord
Grails View taglibs are better than <=%...%> in view
Grails plugins are well documented and clearly state whether they are supported by SpringSource or not
SpringSource is investing heavily in Grails
There will be many more corporate jobs for Grails than Rails in the future, but more startups use Rails (where do you want to work?)
My perspective
I used Rails a couple years ago, I'm working on a Grails project now
I like them both better than Django (Python) or Zend Framework (PHP)
I plan to learn Lift (Scala) next
My Recommendation
If you have never done Java development and are working on a side project for a small to medium website, go with Rails
If you are working at a big company that uses Java, try pitching Grails to your management as the "next Java framework" they should invest in
If you are working on "the next twitter or foursquare," well then you are smart enough to answer this question yourself! :)
First time I begun a project with Rails I was really surprised:
How can I separate "repository" from "Service"? Oh my God: I have to put business logic on controllers... I can't imagine a real big project with Ruby on Rails: Is there Someone on 37signals remembering the basics of separating Business and Domain/Repository. The Rails folders/classes structure doesn't take care about this.
Second sock: "Active Record". Try to design a real complex Object Oriented Business layer and map it using the Rails Models (Active Record)... really: don't.
6 months later, with our project running: R&R is consuming 80% CPU (and memory...) using apache + passanger on a quad core server... and the Postgresql Database is in holidays (3-4% of CPU)... Oh my god (newly)
My old ASP/VB6 applications where capable of serve pages to 300 concurrent users in a real backoffice context with real complex databases and complex business installed on a standalone machine (a year 2001 1 CPU core server).
Of course, conventions and Ruby syntax are lovely... and no one needs a compiler (well... unit tests are used for this porpouses 90% of the time... just for solving the dissapeared typing each time I change some code... "Please, programming god, take care about my fingers mistakes" )
First impession with Grails:
A "Cool" stack inspired on Rails with professional power based on Spring framework (IoC, Hibernate, ...)
And YES!!!
There is a clean Domain/Service separation. NICE!!!
You can, eventually, forget Java.
Rails is fairly mature, has a HUGE ecosystem to go with it. I'm not familiar with Grails or it's support online, but the red flag I see in your post is that you've admitted Grails is playing catch up to Rails.
Ruby is an absolute joy to work with (and this coming from an old C++ hack... why, back in the day I used to program with just a hex keypad, young whippersnapper... now GET OFF MY LAWN!).
There are things about ruby that make it hard to follow at times (method_missing I'm looking at YOU) but I'm sure that can be said about any language.
Me? I'd go with ruby and rails.
Well for grails, i still think that even catching up, it has 2 main things that rails won't have in a easy way:
scaling up
tons of mature java libraries at your fingertips (personally geotools among others)
Ruby on Rails is outstanding - like the Pink Floyd of web dev.
Groovy on Grails is a decent copy of it - kind of like the Australian Pink Floyd show...
BTW - We have both at work - and I have seen many Grails developers eventually learn Rails and stick with it.
I have also seen Rails developers learn Grails, but NONE of them have preferred it.
About half of the time, our Java developers learn Grails and simply stay away from Ruby.
IMHO - If you truly know both fairly well, you will almost always prefer Ruby and Rails.
You also have to consider your IDE. When I started out with rails, it was quite painful. Rubymine was super slow and crashing, everyone I know were using textmate. Grails has STS (eclipse based) and gives you all the features you need.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I wanted to create a web application. I thought of selecting Groovy or Grails. But I don't know from where to start! To start with Groovy or Grails?
If you know Java, go directly to grails. Groovy can be used with pure Java syntax, and you'll be learning its special syntax extras on the way.
I've just been in the same situation.
With my last Java experiences dating back some 7 years, I tried to start with Grails directly using "The Definitive Guide to Grails".
I went about 1/3rd thru and thought I understood enough to start out. But as soon as I started to hack I noticed I simply ran into too many errors that would take me hours to resolve, simply because of missing Groovy knowledge.
So I went and got myself "Groovy in Action" (a.k.a GinA). I studied the whole book and programmed each and every listing myself. As I didn't focus on this task solely, it took me several weeks to complete the 600+ pages.
Then I went back to my Grails project and found that I had even forgotten the things I already had known from the first book.
In hindsight, I would go about the task like this:
Directly start your Grails project (I recommend you setup NetBeans SpringSource Tool Suite IntelliJ IDEA Ultimate as your IDE)
Work on it every day for about one
hour
Learn ~50 pages in your
preferred Groovy resource.
Learn ~20 pages in your preferred
Grails resource.
Apply what you
learned
Keep in mind that the current edition of Groovy in Action is dated 2007 and The Definitive Guide to Grails is dated 2009.
In both cases this is quite old, though almost all of the GinA examples still work.
The most important parts of the official Grails Framework Reference are written well structured in chapters, thus it will suite perfectly as your Grails resource.
The following combination would be my personal choice:
Groovy: Groovy in Action, Second Edition as MEAP (Manning Early
Access Program) ($34.99 or $49.99)
Grails: The Grails Framework - Reference Documentation (free)
I'd love to hear about your success & subscribed to your questions as I might be able to help with some of your simpler ones.
Enjoy!
It may be that you're misunderstanding what exactly Groovy and Grails are.
Groovy is a dynamic language that uses Java's JVM (virtual machine). It can compile to Java bytecode and run anywhere that a typical Java program can run. It's only a language, not a framework for developing web applications. You could use Groovy by itself to build a web application, leveraging Servlets, JSPs, and other libraries to help you. However...
Grails is a framework that uses the Groovy language to help you build web applications. Grails gives you easy ways to create all of the web application components that you'd normally have to build yourself (using Servlets, JSPs, etc.).
This may help explain to you why Bozho suggested to go straight to Grails (and why I agree with him).
If you have the opportunity to deploy on google appengine you should take a look at Gaelyk (http://gaelyk.appspot.com/), which is a Groovy framework that gets you up and running realy fast.
Based on your situation, I would start with grails. Here is the Quick Start tutorial: http://grails.org/Quick+Start
At some point you may want something lighter. When that happens check out Ratpack at https://github.com/bleedingwolf/Ratpack#readme
As a learner like you, here is what I've got in few last weeks.
Even if you're familiar with Java, Grails auto-generates templates of code, and knowing Groovy syntax helps to understand it better.
I very suggest books by Scott Davis, they are just brilliant -- short, clear, and straightforward.
Start from "Groovy Recipes", and then take a look at "Getting Started with Grails".
Gaelyk is good for some very custom webapps, but if you're doing ordinary dynamic website, then too much code has to be written manually, and from scratch. Grails provides much more help here.
If you do not know Groovy or Java, sure, you could go straight to Grails, although much of it will be lost on you. My path has been Grails, Groovy, Grails, and now Groovy full-time.
Groovy provides so much pure goodness (builders, command chaining, closure driven Annotations, Groovy SQL, POGOs, etc.), it would be a shame not to explore it in depth ;--)
I'll get back to Grails no doubt, but I am having too much fun with Groovy right now...
SpringSource (now VMWare) has two very similar technologies: Grails and Spring Roo. I have been using Grails, but I see that SpringSource is actively working on something that is a competitor for that technology and that makes me worried about the future of Grails.
Does anyone know how these technologies relate, are they going to be merged, or one of them will be abandoned?
Besides, are there any important technical differences betweent Grails and Roo?
SpringSource's goal is to make it as fast and easy as possible for people to build, run and manage Spring-based solutions. We have both Grails and Spring Roo because we deeply care about developer productivity and unquestionably both of these tools deliver a serious boost to what teams can achieve on top of Spring.
We have both technologies because Roo and Grails are very different at philosophical and implementation levels (as already noted in the other replies). Each technology approaches its primary language (Java or Groovy) and operating model (dev-time or runtime) with the philosophy of "how do we make the value proposition unbelievably good using this language and operating model combination?". As such you'll see each technology adopting a different style that maximises that combination (Roo's Java+Dev-time or Grail's Groovy+Runtime) and the commensurate benefits.
These differences are actually very positive, because they mean the Spring community can chose which "flavour" of productivity solution they prefer. While these initial differences around language choice and runtime/dev-time operation are immediately apparent, the choice of Grails or Roo also extends to more subtle considerations such as the default technologies used, user interaction model, IDE support, dependencies, standards, roadmap, extensions etc. Nearly all of these differences are a natural consequence of pursuing a best-of-breed solution for a particular language style.
Our best advice is to consider both solutions. Each have their sweet spots, but there are differences between the two which will make your overall experience better with one technology or the other in a given context. Both reference guides detail the respective benefits of each solution. Of course, remember the time investment is minimal in trying both out. In 10 minutes you can build a project in Roo or Grails, so give them a try and see what feels more natural for you given your specific background and project needs.
The main difference is that Roo is a pure Java framework whereas Grails leverages Groovy as well as Java. Both are built on the core Spring libraries and make use of popular Java open source libraries.
This question was asked back when Roo was announced and Graeme Rocher (Grails lead) says that both frameworks have a place within Spring and are supported equally.
If anything, I think Grails has a brighter future than Roo. I love developing with it and don't see any downsides to it not being pure Java.
Grails and Roo are very different. The first major difference is the language used. While you can write Groovy code like traditional Java code you still need the Groovy dependencies to run Grails applications. To be as productive as possible in Grails you also need to have a grasp of features in Groovy that are not currently part of Java such as Closures. Another difference is the philosophy the frameworks take to generating code. Grails generates a lot of methods at runtime while Roo generates them on request during the development process. Roo has no behind the scenes magic accept for the usage of aspect oriented programming, and you can view all the code that Roo generates. For example in Roo you must use a command to have it generate dynamic finder methods such as findByBook() and then view the generated code in the .aj files. In Grails the findByBook() method is created at runtime, and you can’t view the generated code. Roo also allows you to stop using the framework if you chose while continuing to have a running application by merging all the generated code into normal .java files. You then have no dependencies on any Roo libraries at either runtime or design time. If you decide you don’t like Grails there’s no way to stop using the framework while continuing to have a functioning application.
IMO the two are not very similar. Even though there are similarities the following are significant differences:
Roo uses "Stock-Standard Java",
Grails is based on Groovy
Grails is a Web framework, Roo is not
Roo is very similar to Grails' command line system (e.g. the create-app, create-domain-class, test-app type commands found in Grails). I would not be surprised to see some "cross-pollination" between this part of the Grails framework and Roo.
Ben Alex from SpringSource talks about Roo in this interview and he is asked about Grails vs Roo. The main difference besides using different languages (Groovy vs Java as others mentioned) is that Roo is mainly a development time tool and Grails is more involved in runtime.
They're actually not that similar. Roo does it's magic at compile time, where Grails is does it runtime. Because of that Roo projects does not take any performance hits at runtime.
I can't see how they could be merged as Grails is built upon Groovy and Roo on Java.
I saw some comments on the Grails mailing lists which indicated that the authors believed that Roo exists only as a stepping-stone to Grails! However I am personally considering a possible switch from Grails to Roo. I think the main difference is between dynamic and statically typed languages - to me this is huge. I love many features of Grails but I prefer the IDE support and compile-time checking of a statically typed language. Some others feel exactly the opposite, hence horses for courses. That said, static groovy is currently under heavy development so who knows what the future holds.
We had a requirement where we had an application in production and was developed in Spring MVC and the velocity of developing new features were slow. We had to explore alternate frameworks like Grails and Roo. I personally spent close to a month exploring which one was better.
If you want to see the details of the analysis visit # http://krishnasblog.com/2012/05/08/roo-vs-grails/
We explored following features in both these and below is our findings. The final verdict we are not sure we will use either one, we are still exploring
Given that both Ruby on Rails (RoR) and Grails can run on the JVM (Java Virtual Machine), which language and framework enables equally competent and experienced developers to be more productive and roughly by what percentage? (i.e., deliver more business functionaity for the same amount of effort)
I know that Grails is easier for a Java developer to transition to. And I realize that the entire Java Library is available to a Grails developer. My question is regarding developer productivity in an environment where one runs on an JVM on Linux using the standard application servers (WAS, Weblogic, JBOSS, TOMCAT etc.). Note: JRuby will be used to enable RoR to run on the JVM.
I would requests answers from those that have done significant web applications development using both ROR and Grails.
If all you're looking for is a 75% answer: grails
I've done significant development on both platforms, though my major rails experience ended about a year and a half ago (before rails 2.x was released).
I've been heavily involved in grails development since grails 0.5.
The answer really depends quite a bit more on the developers and infrastructure that will be available to work on the project. If you're looking to deploy to a standard java app container (like Tomcat), I think that Grails is the better choice. If you're looking to do something with mongrel/rack/pound/etc. Pick rails.
If there are particular gems/jars that fit your business problem, that would obviously affect your decision.
The choice of Grails for me isn't so much because I think that it's better at solving all kinds of problems, but more because I like the grails developer community better and I like the groovy language a little more.
I've also found grails to be an easier sell to the places I've worked at over ruby/rails. There are many more java shops around here and it's less of a leap for them to make that transition.
This is a personal preference and I could easily see someone else going the other way.
Rails has quite a few things going for it, and I think the test driven development story there is much better (though I'm working on trying to fix that).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Grails vs Rails. Which has better support? And which one is a better choice to develop medium size apps with? Most importantly which one has more plug-ins?
One other thing worth mentioning: the design philosophy of both framework is somewhat different when it comes to the model. Grails is more "domain-oriented" while Rails is more "database-oriented".
In Rails, you essentially start by defining your tables (with field names and their specifics). Then ActiveRecord will map them to Ruby classes or models.
In Grails, it's the reverse: you start by defining your models (Groovy classes) and when you hit run, GORM (Grails ActiveRecord equivalent) will create the related database and tables (or update them). Which may also be why you don't have the concept of 'migrations' in Grails (although I think it will come in some future release).
I don't know if one is better than the other. I guess it depends on your context.
This being said, I'm still myself wondering which one to choose. As Tom was saying, if you're dependent on Java you can still go for JRuby - so Java reuse shouldn't be your sole criterion.
I guess if you are a Java developer and want to have access to all the existing enterprise Java libraries and functionality... go with Grails.
Rails is more mature, has more plugins, has a bigger userbase, has better documentation and support available. It can also run on JRuby giving access to Java libraries if you require.
Grails has some interesting qualities, but can't claim to be up there with rails just yet. However, if you're predominantly a Java or groovy developer you may prefer it. Otherwise though, I'd suggest using Rails for medium sized projects right now.
I say grails since there are so many java libraries out there. But I am a bit biased due to the fact that I come from a java background.
If the app isn't going to be big, either suffices - and the choice ought to depend on existing infrastructure. Say if you already have a java servlet container server running, you might as well stick with grails instead of provisioning another server for rails.
I used rails before and liked it quite a bit. However, my current company had a lot of legacy java code and therefore the natural choice was grails.
When I started with rails, very few sites were using it and documentation was atrocious. There was railscast that was great and railsforum.com, but anything out of the ordinary, you're on your own. Deploying it was a nightmare, and using mongrel-clusters was not really production ready. This is very different now as everybody can see, much more mature and deployed everywhere.
Over a year back, I had to learn grails due to reason I cited above. Transitioning to grails was very easy, since it is very similar to Rails. Again, it was very similar to the early stages of rails, with one huge difference. Because you can easily import java code, grails users can use almost all the production tested java libraries available out there. I've been able to successfully integrate our legacy java projects into grails projects and very little tweaking are needed. You will also notice that plugin development has been rapid, mainly because developers are just writing grails "hooks" but the underlying code are the old java libraries. Deploying grails is also just deploying a WAR file.
Another thing you have to look at is IDE. If you're comfortable with eclipse, then eclipse-STS for grails gives you all the bells and whistles. I still see a lot of rails developers use textmate, though rubymine has made great strides (the early version of rubymine used to grind my ubuntu to a halt).
The bottom line, both are great MVC frameworks. RoR is much more mature and has a lot more developers. Grails is where RoR was 3-4 years ago, but I see the progress a lot more faster. Hope this helps.
It depends on your skills with Ruby and/or Groovy, whether you have legacy Java systems to deal with, and where you want to deploy your applications.
I was initially thrilled with Rails. At the time, there wasn't an option of deploying on the application servers at work since work is all Java. This has changed. I couldn't abandon the Java infrastructure and applications already in place and switch to Ruby, even though I thought Rails was awesome. Grails works because we can mix and match Groovy with the existing Java solutions.
Outside of work, Ruby is easier to find hosting for at the low end of the price spectrum. Because Grails uses a lot of existing Java projects the .war files, even for a small app, tend to be large. If you have a dedicated server this isn't a problem but trying to run on shared hosting with 128 MB RAM doesn't work.
2008 is the year of Groovy and Grails books but there are still many more Rails resources available.
Based on your specific criteria, Rails may be a better framework to learn. If you have any Java knowledge, or baggage ;-), you should look at Grails.
Seeing as how the guys who make Grails just got bought out by Spring source yesterday, I would say Grails.
Also, since Groovy is a superset of Java, you can dive right in just using the Java you know without having to learn Ruby. Now, you'll learn a lot of dynamic stuff too and eventually write Groovy code instead of Java code, but it lowers the barrier to entry.
Grails all the way!
I would go with Grails since I like its approach (specify your domain classes and have Grails generate everything else) better than the Rails one (build database tables and have Rails generate everything else). If you're a Java developer, you'll also like that Java code is valid Groovy code, and a Groovy class is a Java class so the integration is seamless both ways.
As a Grails developer coming from Java, I loved it from the very first time.
Now, I'm starting to dig into Rails and having problems with gem. While MySQL connection setup with Grails was pretty straightforward, I'm still struggling to make it work with Rails.
The command gem install mysql is not working, apparently because I don't have XCode intalled.
If it weren't for its memory consumption issue, I'd say Grails is perfect.
May I suggest Merb? It is rack-based, modular, ORM-agnostic, built for speed from ground up by Ezra Zygmuntowicz. It is starting to gain some heat now...
Rails is more mainstream, but less flexible. Grails is still changing rapidly, doesn't have the same developer ecosystem, and the documentation isn't nearly as mature, but it will work in some situations Rails won't.
I have used turbogears and rails a little bit. Before using rails, I tried using grails because I was using groovy for my scripting. Grails was a difficult experience.
The groovy call stack is difficult to read for a small program, but when you add in several heavy weight frameworks a simple error can yield 100s of lines. Unlike rails the grails version that I was using didn't have tools to help me determine what was mine and what belonged to the framework.
I eventually switched to using the Google Web toolkit since I really didn't need the database.
I think Grails and Groovy hold promise, but the user experience of working with them is cumbersome at present (present being last spring).
I think it depends on the environment you're working in to some extent.
Grails seems to have more corporate level acceptance.
Rails has the Koolaid-vibe, and is very acceptable for start-ups with no legacy systems.
Personally I'm using both. Though only really just starting out in the Grails world - I like that authentication/authorisation is easier in Grails-one simple plugin; Shiro. I like that Rails isn't dependant on JVM, and doesn't take a minute or so to startup.
I find setting up BDD/Cucumber within Rails was far easier, but that could just be because that's what I'm comfortable with! There's definitely efforts in the Grails world (cuke4duke etc) to make this easier-and an active community developing Grails.
Just my 2p·
Try both :)