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...
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am starting a new project with Grails and currently have no experience in it. Grails 3.0.9 is the latest version, but I have read that some plugins are not yet compatible with Grails 3, is this true? If this is true, should I consider a previous version of Grails?
Being unexperienced in web development, I am not yet sure what plugins I will require and am therefore unable to properly evaluate my need for those that aren't useable. Do the pros of using version 3.0 outweigh the cons? Or by using the latest version do you think avoiding the hassle of upgrading plugins in the future be something worth considering above all else?
Answer to Which version of Grails should be used could vary from person to person and is highly opinion based but there are some factors that could make the decision easier.
Especially I would talk about grails 2.5 and grails 3.x versions.
Reason to Choose 2.5 version:
Well built plugin support and a wide community help available.
Lesser number of bugs are there in 2.5 version as compared to lower versions but is heavy and is low in development time performance.
Good integration with IntelliJ idea is there for newer version.
You could move fast with 2.5 due to good documentation available.
If you have no plan to upgrade grails version ever in future and the project size is smaller.
Reason to Choose grails 3.x
Though good plugin support is not yet available, I would say you may use java libraries after all and no way blocked. Most plugins just provide an easier way to setup the library environment and some helpful tags etc which we could also create ourselves. Hence it could be a bit time consuming in setup but would be faster in development later especially when you override plugin features.
grails 3.x is on gradle which makes it highly recommended to be used as compared to grails 2.5. Gradle is ultimate build tool that has over come a lot of issues or weaknesses of older build tools.
it supports spring-boot and spring at it's core but is more diligent in using it. It gives enormous power and possibilities and flexibility just like any java project.
It has become lightweight now and comes with least configurations which makes it good choice in terms of performance.
Last but not least it comes with spring 4.1, groovy 2.4 and support for traits and enhanced IDE integration.
These seems some good points to consider while making a choice for grails framework.
In last this may have several opinions from experts but ultimate choice should be the newest but with good reviews only.
Edit: Elaboration of certain points which may not be obvious to all.
supports spring-boot and spring at it's core but is more diligent in using it :
spring-boot is the quick start helper for any spring application and is used just to get you started with spring and nothing more than that. In other words, it reduces count of your dependencies in maven or build.gradle.
grails 3.x provide public static void main(String ..args){} method as entry point to run your web application which makes it more springy. At the same point you could integrate any customisation required. You could run web application like a normal java/groovy main application. By diligent, I mean that things has been integrated carefully this time and not like old buggy grails version. There could be bugs here in 3.x as well but it's way better than 2.x.
So when you start working with grails 3.x you will feel working on spring with same artefact level feel i.e. domains, controllers and services would all behave same as earlier but you will notice configuration level changes like yaml files, libraries used etc.
In one sentence, after all it's spring / hibernate used inside, you know spring/hibernate you know grails more than anyone else knows
I am new to Grails as well. Just started to learn and doing a project for the past 5-6 weeks. I'm using 2.4 and still finding that some useful plugins are not compatible. Also a lot of books and documentations are done with 2.3. I'm thinking about redoing my project in 2.3 to make my life a bit easier.
Yes, as #vahid mentioned, good for learning. I first need to figure how Grails work with good examples.
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 12 years ago.
I know that there have been plenty of topics describing this topic but I still can't put up my mind what to choose.First of all, I need you to know that I am a student in his last year, who will probably continue studying for a few years. However, I'm trying to find what I would benefit most from.
I've been in contact with RoR last year; seeing Ruby's squirky syntax amazed me, and Rails CoC and DRY principles make me dream. I've written some scripts to generate sql statements in Ruby, but that is about all.
I'm considered to be a java developer, as they call me the java guy on school, (no, i do not consider myself good, on the contrary, every day I realise more how much more i've got to learn). Now, I've taught myself several technologies related to java. To make my work easier, I opted learning hibernate and maven. Now we are developping an application in Spring + Spring MVC.
Grails caught my attention lately since it is built on top of these technologies, and uses a language that is similar to java, and allows access to java classes.
However, i'm not sure what is the best way to go. Should I struggle through Ruby's quirkyness first, and learn Rails? Or would learning Grails first give me an advantage over learning RoR?
Also, as far as from what i've read, RoR would give me a bigger advantage on the market than grails would; but how do I get a "proof" that I can use RoR? Would it be enough to be able to show applications made using RoR?
I've used both frameworks pretty extensively, and both have their warts and advantages, but when you come right down to it, there aren't that many differences for someone coming from your background.
In my area (Minneapolis), the grails market is larger than the rails market, but that isn't the case everywhere.
I'd pick whichever one has the user group in your area that you connect with the most. That will be your best bet for finding work with whichever one you choose.
You've mentioned that you're already into Java, Spring and Hibernate. Well, Grails is based on those - in continuation.
Spring is a very comprehensive, powerful, and modular, framework. Hibernate has been a de-facto standard, and is compliant with Java EE 6's JPA. Both are most relevant in the Java world.
So, there's the aspect of consistency of your technical knowledge. From Spring/Hibernate to Grails/GORM you'll have cohesive knowledge.
Another central aspect is your options. When dealing with Spring, you'll probably soon learn how easy it is to change complete architectural layers, like, changing the view technology, or database layer, or simply exporting a web service by configuration. Spring-based applications can be highly modular, and you can plug-in almost any technology scope you could think of. - So you have many ways to go further if desired.
The Spring framework has been written from the ground to foster best practices. Just dealing with that framework will teach you a lot.
Admittedly, I haven't dealt with Ruby on Rails, at all. I regard it a rather isolated technology, while Grails is a (Java and Spring) integration framework to me, with the backends/grounds and options as mentioned above.
When evaluating practical aspects of technologies, it's always a good idea to do some research on Google Trends and Indeed job trends. Other indicators on popularity/relevance are the numbers (and trends) of mailing list messages for Grails vs. Ruby on Rails, and (not quite an accurate measurement for niche languages) the TIOBE programming languages index.
Finally, Java had experienced several years of starvation and uncertainty in the past (despite of being one of the few all-time languages and frameworks, at all, and a long-burner). Recently, however, several evident signs came up that appear to seriously forecast a much brighter future than before.
As a Grails developer...
Grails runs on mature and proven virtual machine (JVM) and really do the best performance compared to any dynamic language, even static Java/JSP when using Freemarker Plugin! http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/
Grails uses Groovy, so it has an almost flat learning curve for Java developers. You can write Java syntax and gradually learning Groovy syntax, closures, meta-programming and more... getting expressiveness and agility of a dynamic language like Ruby.
Grails uses modern principles and practices like Convention over Configuration and Scaffolding, just like Rails taught us all.
Grails uses a mature platform, so it comes w/ all great existing java libs, mature groups and projects like Apache, Eclipse, JBoss and so on for reporting, file exporting, legacy integration... and many new well-supported libs and frameworks from Google and others like Guice, Guava, Collections and so on...
Grails uses a vastly used platform, so you can reuse all your existing java libs. You could reuse your entities, utilities, and so on...
Grails use existing Java infrastructure, so it comes with many ready & mature server w/ great documentation (i.e install, configuration) Tomcat, Jetty, Glassfish, and so on...
Grails use existing Java infrastructure, so it scales very well w/ many ready & mature options: Server Clustering, Open Terracotta, Second Level Cache, and so on...
Grails runs on top of well-know and vastly documented frameworks like Hibernate, Spring MVC, Hibernate, SiteMesh, and so on... and you can step down into abstraction when you need, i.e batch imports, complex reporting queries, complex interfaces, and so on..
Grails has a great plugin ecossystem much like Ruby Gems and can use all existing Maven-based lib repositories to resolve dependencies.
Grails uses a solid platform, so you'll always reuse your libs (JARs) with the next Language of The Year (LOTY). "Write Once, Run Ever"
Hope that helps! :-)
If you liked Ruby's syntax and simplicity, go with Rails, and run it on top of JRuby, which will give you access to Java classes as well.
Check: http://blogs.oracle.com/coolstuff/entry/using_java_classes_in_jruby
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
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 :)
My company is in the process of starting down the Grails path. The reason for that is that the current developers are heavy on Java but felt the need for a MVC-style language for some future web development projects. Personally, I'm coming from the design/usability world, but as I take more "front-end" responsibilities I'm starting to feel the need for learning a language more intensively so I can code some logic but especially the front-end code for my UIs and stuff.
I've been trying to get into Python/Django personally, but just never invested too much time on it. Now that my company is "jumping" into Grails I bought the "Agile Web Development with Rails (3rd Ed - Beta)" and I'm starting to get into RoR. I'd still like to learn Python in the future or on the side, but my biggest question is:
Should I be learning RoR, and have a more versatile language in my "portfolio", knowing that my RoR knowledge will be useful for my Grails needs as well??
-OR-
Should I just skip RoR and focus on learning Grails that I'll be needing for work soon, and work on learning RoR/Django (Ruby/Python) later?
Basically the question revolves around the usefulness of Grails in a non-corporate setting and the similarities between Rails and Grails. (and this, while trying to avoid the centennial discussion of Python vs Ruby (on Rails) :))
Mmh, I don't know how to say this. Some people might bash me over this.
Language (Groovy and Ruby)
As a language I reckon Ruby is more funky compared to Groovy. Groovy only exists to ease Java programmer as you don't need to learn too much new syntax. But overall I reckon is not as funky as Ruby. Groovy wouldn't be the JVM language that is worth to learn based on attender's vote in this year's JavaOne but instead Scala is the one to go. Besides that, the original creator of Groovy himself does not have faith in the language he created himself in the first place.
Community and Job openings
As for the community, Grails community is not as big as Rails, though since the acquirement by Spring more and more people are using it in serious application. Rails has more job openings in the market compared to Grails (that is if you want to invest in looking a new job).
The framework (Grails and Rails)
But, as a framework, if you really care about maintainability and need access to Java framework and legacy Java system, Grails is the way to go as it provides cleaner access to Java. Grails itself is built upon several popular Java framework (Spring & Hibernate). Rails itself IMHO is funky like Ruby itself, but it's funkyness costs you maintainability. Matz himself prefers Merb over Rails 2 because Rails create a DSL on top of Ruby which is really against the Ruby philosophy. And I reckon because Rails itself is opiniated, which in turn if you don't have the same opinion as the creator, it might not fit your needs.
Conclusion
So in your case, learn Grails as that is the company's consensus (you need to respect the consensus) and if you still want to secure your job. But, invest some time learning Rails and Ruby too if you want to open a chance getting a new job in the future.
Just a bit of a question, is the reason they are choosing Grails because Groovy is closer in syntax to Java than Ruby, or because they want access to Java?
If it is the former, then I would say try to focus on Grails since that is what you will be using. If it is the latter, you might want to see if the development team is open to using JRuby.
I have never used Grails or Rails before, but I have used Groovy and Ruby before, and as a language I think Ruby is much cleaner and more consistent, and the team might enjoy production more. As a platform, Rails has been out longer and has a lot of attention, so I would imagine it is a more stable platform to use with more fleshed out features.
JRuby has full access to classes written in Java, so this is why I would say consider trying Rails. If it is too late in the decision time to consider it then I guess you can just ignore this post.
Basically, if you just want to hook in with Java, then JRuby is an option you should consider, but if the team is afraid of non-Java like syntax, maybe continue as is.
I would learn both. They are both up and coming technologies. Learning RESTful coding is a real benefit in any language.
I use GRAILS at work and RoR for side projects. I can say that the RoR community is much larger (I'm talking about RoR vs Grails not RoR vs Java) and very helpful.
Short Answer: They are similar.... what could it hurt?
Just skip RoR. There are really not a lot of similar things(besides the name)
I certainly believe that being enough familiar with Java, plus some experience programming with a dynamic language is more than enough if you plan to do serious development with Grails.
Comparing just only views(taglibs in Grails, RHTML in RoR) and the persistence stuff(GORM vs ActiveRecord) is just too different in the core, to invest time learning the nitty gritty details of RoR. Just dive into Grails, you won't regret.
Edit: corrected typo.
I've been learning RoR and Grails and the latter is far easier to learn.
Both frameworks share the same principles (agile, kiss, dry, duck typing and so..) but Groovy syntax is...well is simply great, something you can learn and use in a blink of an eye.
I truly feel that Grails has brighter future than RoR.
PD: Just in case you find it useful, a college of mine it's working full time with Grails and has a blog with some tips:
http://dahernan.net/search/label/grails
You should just skip RoR and focus on learning Grails that you'll be needing for work.
#Levi Figueira
For one thing, Grails is far more flexible than Rails. Rails is difficult to use with a legacy DB because ActiveRecord has too many design constraints that many legacy DBs didn't follow. Grails, oth, can use standard Hibernate mappings, which can accommodate a much broader range of DB designs.
The Rails community has been very vocal in evangelising RoR, with the result that high expectations have been set and not always met (programmer productivity is good, but ensuring good performance once deployed isn't so easy).
Grails has been designed as the scripted successor to Java, whereas the Ruby-Java integration used in JRuby on Rails, for example, has had to be retrofitted.
I would suggest that you stick with Grails; it may not have the same glitz as RoR, but it's a pragmatic choice; you get improved productivity and the re-use of existing Java libraries.
Jump straight into Grails. I'm sure Ruby/Rails is good but so in Groovy/Grails. I recommend this book.
http://beginninggroovyandgrails.com
Remember the errata is online. There are a couple of mistakes in the book.
http://beginninggroovyandgrails.com/site/content/errata
Also, check out the 3 minute and 30 second demo of creating your first Grails app.
http://grails.org/Grails+Screencasts
This tutorial will show you the basics.
http://grails.org/Quick+Start
Yes Grails is the way to go. RoR is good but it ties you in to the Ruby ecosystem. Part of the effort of learning a new framework or language is learning the class libraries as well as the language syntax. If your co-workers are all Java types you will be much better placed to receive help and support as they will all be speaking the same language as you.
The other advantage to learning a bit of Groovy and Java is that web frameworks like GWT will open up to you. Grails has a GWT plugin and as a front end developer you will appreciate the ease of use and cross browser compatibility.
Also there is at least one hosting company offering free Grails application hosting (http://www.mor.ph/) which means that you can prototype sites at small data volumes before having to pay.
I favor Grails over Rails, but learning Rails will give you a more balanced perspective and actually open your eyes to overlooked things that are possible in Grails.
At a first glance you would think they are completely differente stories, since they are based on extremely different languages (Ruby and Groovy).
Then, after reading a couple of tutorials, you'll realize they share the same principles, scaffolding, duck typing, .. and finally the same goal:
making agile programming feasible.
If you already feel comfortable with terms like IoC and MVC, you'll find any of these options easy and exciting to learn.
I would say no, I'm learning Grails as well, and I've considered this as well, but just learning Grails is pretty big, plus learning Groovy (which granted is easy, but still gotta learn it right?) and all that... so learning Rails would have been just too much.
Yes if we compare grails and rails I would choose grails (I developed some intranet applications in grails).
But Django is superior to both - as python is well hmm a perfect choice.
You might also want to take a look at Clojure, a JVM language that's just starting to get popular. It may be a good choice for a Java-based company since it's compatible with your old codebase, and has a lot of modern innovations going for it. There are some good web frameworks emerging, including Compojure.