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

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

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

For book updates, follow @angular_book on Twitter.

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

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

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


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

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 15 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 08: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 09: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:

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 10: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 11: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 11: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 08: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 11: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:

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.


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 #

My $.02 on this - having used both. Full disclosure, I come from a Smalltalk background, so learning Java and how to use it well was a bit of a pain. I like the Ruby language a lot. I like very much where Groovy is going.

My experience of setting up a rails environment results in a counter intuitive conclusion. It was a breeze on my brand new Vista machine. It was a total pain in the patoot on my Ubuntu box. Nothing worked quite right on the Ubuntu box. I got it done - in about 6 hours vs about 30 mins on my Vista box.

I think that as long as you are using a full fledged IDE, you can do equally well with Grails and rails. They are both very well thought out frameworks, with Rails having the maturity edge. IntelliJ has a couple of terrific IDEs/ IDEA for Grails and Rubymine (just out as of Jan 2009) for Rails. I can't imagine doing development in either Grails or Rails without a potent IDE. Sure it can be done, but I could also clean my teeth with the frayed end of a twig. Doesn't mean I have to like it.

Performance? I can't comment. I haven't done performance/scalability testing in anger.

Deployment - Rails currently wins this one - easier, but that's just a maturity issue, not an architectural issue.

Testing Rails - again maturity.

So, it comes down to preference. You can do a great job with either. You can also do a crappy job with either. If you started in Java you might like Groovy more, but as I say it is all personal preference.

Posted by Chris Bird on February 04, 2009 at 08:14 AM MST #

What I really don't like about Rails is a cocky community.

I have been to both camps (projects, conferences, trainings, whatnot): Java (Spring, Grails, etc.) and Rails. While I meet very different people in Java and Rails worlds, and while regular Rails developer personalities are different (good, bad, ugly), the top that drives the Rails community (Dave Thomas, Chad Fowler, etc.) is limited as they don't not see the IT world beyond Rails - "JEE is so freaking old and bad", "Zend is a mess", "Django is a kid compare to Rails", etc...

There are awesome people in Rails community such as Ryan Bates, Gregg Pollack, Jason Seifer, etc., but unfortunately, they are not at the top (yes - there is a top), and the arrogance is driven right from the top of the Rails community.

I do like Ruby language a lot, it is elegant, powerful - it's just right. And while Rails is just a fat MVC/ORM wrapper around it, it seems to me that it "shields" the prosperity of Ruby on a long run.

Since November 2008, Grails is backed by Spring community which is a lot more powerful and open minded than Rails. And, while everybody here is so polite and cautious in their opinions about Rails vs Grails - I definitely choose Grails, since a life span of technology is not based on anything else but its community.

Posted by A. Gile on July 05, 2009 at 03:24 PM MDT #

A. Gile- Do you also forsake using Oracle because Larry Ellison is "cocky"? Such an odd criteria. I think you'll find a good mix of people in most communities. I really don't think I would classify Dave Thomas and Chad Fowler as being arrogant or not seeing the world beyond Rails, quite the opposite, really.

Marketing open source projects is a bit of a weird endeavor, so you occasionally do run into statements that seem like attempts to persuade an audience that x is better than y. However, choosing not to do something because of that is like saying you don't like the taste of a soda because of the marketing slogan. It's even weirder in this case, because you are likely basing your perception of what the metaphorical slogan is on a single individual (DHH) with whom it is unlikely that you'll ever interact. Still, whatever gets the job done for you, just do it. Cheers.

Posted by MattMc on July 06, 2009 at 07:39 AM MDT #


Good analogies, however the difference between Rails and Oracle is Oracle is by far the most mature DB kid on a block, and Rails is far from being the most (mature MVC framework).

The good thing about choosing soda is that you go to the soda isle and you have hundreds of items to choose from, and yes, if at any given moment I look at random 2 soda brands, which I both like, but soda's B slogan is "let's worship death to others", I'll go with the soda A, and(!) I have hundreds more brands to choose from...

I do like Ruby, as I said, and I actually do like Rails - have nothing against it besides its "let's worship death to others" slogan driven from the top. That what makes Rails a 'B framework' for me.

Btw, when I said "Dave Thomas, Chad Fowler, etc.", I did not miss DHH - he is a creator and I respect him for that. And I do not know why it is so "unlikely to interact with another human being", because I did interact with him as well as with Dave, Chad and others.

It's a funny coincidence but I don't like soda at all :)

Posted by A. Gile on July 06, 2009 at 09:09 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed