Is Grails (now) worth it?

Question

I know this is a duplicate, however, the Grails world has moved on considerably since that question was asked more than a year ago, as has the IDE support in Eclipse, so please don't just blindly close it.

I thought the answer was yes and have embarked on a new project with Grails 1.2.0 and have flirted with the Groovy/Grails bits of the STS Eclipse Integration.

I think the question deserves revisiting after a year of Grails evolution, when the answer was definitely mixed.

So, as an experienced Java web developer I have these questions and would appreciate my assumptions being challenged:

• Is Grails now worth it vs. Ruby or roll your own?
• Has it overcome its buggy start?
• Does it really confer rapid development benefits? (I admit I am struggling now I am past the extensive baseline configuration to make my bespoke app which is not list and page oriented)
• Does it perform for real world production apps? (It feels heavy)
• Is the Eclipse plug-in better than it was and fit for purpose? (I think not yet)

Thanks

EDIT: I am learning as I go and I have a couple of significant gripes to make about living with the framework - rather than framework capabilities themselves. I am adding these because I think they should be considerations and are based on my experience and opinion, and may help someone who is trying to decide whether to go grails. I may also be showing my lack of experience with the framework, so none of this is meant as out and out criticisms. I am an experienced developer and this is what I have found:

Debugging is really hard. In fact it is almost impossible, especially as a beginner in the framework, which is when you need your trusty debugger friend the most. I have spent way more time than I ought to tracking down problems of syntactical errors in some part of the code to do with referring to domain fields which cause silent failures somewhere in the stack.

Logging is frankly awful. You have two modes, "nothing useful" and "an inordinate amount of useless stuff". My debug log was 128Mb after a single page request and contains nothing about my error. The whole issue of logging needs reconsideration in the framework in my opinion.

The STS Eclipse IDE is of marginal value. Other than syntax hilighting it is not much use. You can't debug the code so it is a glorified editor. The code hints are patchy and there is no GSP support at all as far as I can see. It also is the slowest Eclipse plug-in I have on my desktop - by about 2 minutes to start up. It is shockingly slow. I have reverted to a text editor (which you'll notice all the online tutorial videos do too) and some custom syntax hilighting.

I have some serious concerns about performance. A bit too early to say, but I am already finding myself tweaking the database because of hibernate. Perhaps that's to be expected, but I am really having to keep my domain model simple for the conventions to yield performant queries.

And one last one, the convention that your logical domain model and your physical database model should be identical is not a smart default and unlikely ever to be the case in the real world. I know you can separate the two, but it creates a degree of complexity which I think could be avoided if the conventions were extended. There is inadequate documentation about composition and what you need to do to make it work in practice.

Solution 1

I have been using Grails more than 4 months now and I will try to give you my personal feeling about Grails and its usability.

Is Grails now worth it vs Ruby or other roll your own?

Of course, the answer is not 'Yes' or 'No' but it depends. It depends on your requirements (do you need to be in the Java World?), on your preferences as well (do you prefer the domain-oriented development, do you prefer Groovy...)? However, I can answer that Grails is a serious alternative to Rails. I believe that whatever is your Rails application, you can do it with Grails as well. But depending on the nature of your project, it might take more or less time. Again, if you are familiar with Rails but not with Grails, Rails is the safer option.

Has it overcome its buggy start?

Yes. If you take a look at my initial messages (in this website or others), I was complaining a lot about Grails bugs. But, you just need to remember that Grails is a little rough on the edge (not too much use of domain inheritance ,for instance) and once you are familiar with the framework, you don't experience too much bad surprises. I am not saying that Grails is not buggy. It is certainly more than Rails. But also, it is more usable than buggy. A piece of advice for that : use as few plugins as possible. Because many of them are buggy and some are not compatible among themselves. So, do not include grails plugin unless you are sure that the grails plugin is up-to-date, non-intrusive and tested (by yourself).

Does it really confer rapid development benefits?

Yes. You almost do not need to deal with DB design. Configuration is almost done for you from the beginning thanks to Convention over Configuration. Your application is easily maintenable. The only drawback I see is front-end development that is not as rich as other technologies (like Rails or ASP)

Does it perform for real world production apps?

I cannot say because I still didn't go my website live but I am pretty confident since sky.com is using Grails and the sites attract significant traffic - around 7 million page views per day . Again performance depends a lot on your application architecture and design decisions.

Is the Eclipse plug-in better than it was and fit for purpose?

No idea. I am using IntelliJ but I guess it is not much better than one year ago according to complaining messages I see on the Grails realm.

I hope it helps.

Solution 2

Started a Rails project recently, had been doing some stuff with Grails.

My main thing with Rails is that there's a lot of stuff that is completely opaque to the dev (which i hate), and this tends to increase when you start to add more plugins/generators/libs/etc, because in order to combine them you will need to patch something up. You get the feel that rails+plugins are just a giant DSL hack that starts breaking if you use some wrong combination of plugins+versions.

With Grails, although the ecosystem is far smaller, everything tends to be relatively consistent. The DSL approach is not very used, and by using conventional-but-boring design (I mean using classes,interfaces,etc. instead of DSLs) it's far easier to understand how the plumbing works.

Doing a 1-to-1 comparison, here's how it goes:

• Language Implementation: I prefer Ruby over Groovy, although I don't know Ruby that well. Groovy feels like a good-intention-bad-implementation language, where some of the features are welded on top of the syntax. I'm referring to some special classes that seems to be there only to allow some hack.
• Framework Features: Rails is far ahead on this one. You can configure most aspects of Rails (ex: layouts, templating, css/js packers, validation, testing frameworks, etc) in several ways. Grails is lagging on this, although its flexible enough for most use cases.
• Plugins: Rails has a ton of plugins which can be seen as a blessing or a nightmare. Some plugins are not maintained, others do not play well with some feature or plugin and there's alot of forks. I'm learning to stick with the basic and most used plugins (authlogic, haml, etc) Grails has excellent plugins for the basics (authorization/authentication, ORM, etc) and some other plugins for smaller stuff
• Testing: Rails has a ton of ways for testing, but this is not necessarily good. Some testing frameworks do not play well with some plugins, etc. Grails has less testing plugins but again they tend to integrate better with some of the main plugins (because there aren't that many plugins to integrate)
• Database: Grails wins by far.
  • I prefere modelling my domain classes instead of hacking my db.
  • Hibernate (which is used under the hood) is years away from its Rails counterpart. Although there's datamapper for Rails (which is more similar in nature to Hibernate than ActiveRecord), I feel it's not mature enough. Grails also have migrations throug a plugin.
  • You have great cache impls for Hibernate (JBoss cache, EhCache, etc) which can boost your performance through the roof
• Libraries: I feel that Ruby has alot of libraries for new stuff like NoSQL or Cloud services, while Java has a gazillion of libraries for older stuff like Excel processing. Don't forget that Java libraries are usually much faster than Ruby
• Cutting edge: Rails is more hype, which translates to having more resources behind it. This means that if you'r trying to integrate MongoDB or Riak with Rails, there's a good change that someone has already made it. Grails is lagging, mainly because it is not so popular so the community tends to focus on solving day-to-day problems instead of using all the bleeding edge stuff like NoSQL,etc

Here's an example:

• Most grails plugins generate code in the form of models and/or services. The rest is usually handled by a library. You can inspect the model/service code, see what it does and change it.
• Most Rails plugins usually hook up with the Rails API, which means that you end up calling some function or including some module, and then use the plugin's own DSL. This works great when it works, but when it breaks it's horrible and you end up having to patch some stuff, or install a different plugin or plugin version. I'm guessing a more seasoned Rails dev is more comfortable with this but I'm not.

---

Conclusion:

• If you want bleeding edge, don't mind some occasional patching, favor a large community and/or don't mind using ActiveRecord-style DB, go with Rails. Besides, Ruby as a language is very elegant
• If you favor class-interface designs instead of DSLs, prefer modelling your app through models, don't need exquisite features and are familiar with Java ecosystem, go with Grails

Solution 3

It's highly worth it!

We are using Grails in several projects, all of them with great success for the following reasons:

• Easy - It's one of the easiest frameworks we ever used

• Legacy code reuse - All we have to do is get our legacy code and throw it on the lib or src folder and it's done. Just great for us.

• Legacy database structure - It's an awesome tool if you wanna generate data visualizations on legacy databases.

Now, about viability:

• Bugs: we haven't faced too many bugs since version 1.1 (version 1.0 was WAY too buggy for us)

• Tools: Netbeans is really improving on this front, but it's not even close other tools like Intellij IDEA (great support!). The same can be said about Eclipse.

• Portability: we never faced a single problem on our projects.

Solution 4

We have half a dozen Grails applications in production now, and while Grails is different from java frameworks and requires some learning time, it has paid off because we have used Agile techniques. Details:

• We use IntelliJ. It's not very expensive and is has paid back in a few weeks for us.
• Automated testing, Continuous Integration and refactoring are a must, as for for all dynamic language code. If you already practice TDD or at least have a decent test code coverage, then it doesn't add any extra work.
• Hibernate comes by default with Grails, but you can use other persistence frameworks. There are 5 persistence plugins other available today
• Logging was clearly not a concern in Graeme Rochers' mind, but it has steadily improved. I haven't faced an issue where an error was not logged, though (you have to make sure you catch exceptions correctly in your code)
• Debugging was clearly not on the radar (but this has not improved). We don't rely on debugging anyway.

This said, as with all new technologies, I recommend making prototypes, code reviews, pair programming, and maybe use some consulting as well.

Solution 5

It is very much worth it. I've been using it for over a year now and love it. I used to shy away from these types of rad tools, but it has changed the way I work. With the 1.2 release it has gotten even better with better stack trace info (particularly for GSPs).

The only problem I have had with scaling has been hibernate and it's cache, which really isn't a grails issue. Even those I don't like hibernate in general, the way grails wraps it with GORM is a work of art to me. The criteria closure aspect is wonderful to work with.

View more solutions

Comments

[Kico Lobo]

Simon, take a look at this project manubia.com.br It's a personal finance manager 100% done in Grails. It shows excelent performance.

[Jean Barmash]

The question asked about the state of Grails now, as opposed to a year ago.

[Kimble]

I second the point about the plugins. You have no guarantee that plugins will be updated for newer versions of Grails. I would recommend that you stick with those backed by Grails / SpringSource.

[opsb]

As we've been considering which technology to adopt at work I've been following the progression of grails closely. My points are still valid today. If you're looking for a technology that improves productivity for a wide variety of requirements you're going to experience disappointment with grails where you won't with rails.

[Ben Doerr]

Plugins are an interesting bunch in the grails community. If you look at plugins as black box that you use with your app, then I think you are going to have problems. But if you look at plugins as templates that the grails community has provided you will get along much better.

[Simon]

I am using this, as I said in the post. To be honest I don't think it is great. It gets quite a lot of benefit from just being an Eclipse plug-in, but the specific support for groovy is not great and gsp is almost non-existant. I would have expected that you had a way of performing the basic grails commands too but you have to go to a command line as far as I can work out, which defeats the purpose of an IDE. A long way from fit for purpose I would say.

[deamon]

Grails support of NetBeans is fine.

[Reverend Gonzo]

Huh? It's right there. Project->Navigate->Run Grails Command. (or something like that) Windows users even have a shortcut.

[peninha]

You're right, it could definitely be improved, but as far as eclipse support goes, it beats by far the almost non-existent support that eclipse had to grails before. But I personally don't mind the command shell, it's especially handy for plugins commands

[Mr. Boy]

Even Ruby on Rails performs, as long as you throw enough servers at the problem - I think you have a different idea of 'performant' to other people. Hardware may be relatively cheap compared to developers, but running dedicated servers certainly costs a bundle and having to throw servers at a problem suggests the software is not good enough... if you need multiple servers for any non-major site, you're doing something wrong.

[mcv]

That depends entirely on what that non-major site actually does. Lots of servers that nobody ever heard of require clustering, not because the language is slow, but because the code is that complex. But some languages (like Ruby) really are slow. But even a slow language doesn't have to be a problem if you can afford to add more servers. Is that wrong? That depends entirely on the situation. At some point it's definitely worth it to rewrite the heavy stuff in something more efficient. But when you're starting out, efficiency of development may be more important than efficiency of execution.

[Levi Figueira]

Spot on. It's sad but so true: technologists (aka programmers) who are afraid of changing even when it means for the better…

[virtualeyes]

Were you not following, but working with Grails 1.3.6 you would say otherwise. I tried and gave up on Grails < 1.3 due to devel reloading (or lackthereof) problem, but have gotten back onboard with this crucial issue solved. GORM is a masterpiece, persistance layer is completely taken care of, and elegantly so, unlike AR for example, where many Railists call for a decent alternative (like Sequel). Communities are vastly different, Groovy/Grails: mature, serious minded "enterprise"y; Ruby/Rails: young, dynamic, avant garde, push the limits, if it breaks no bigs, patch and onward we go ;-)

[Victor Sergienko]

Actually, debugging with IntelliJ Idea is as straightforward as it can be, besides of minor inconveniences like having to expand watch variables.

[Victor Sergienko]

When comparing releases you should name them. Personally I, being happy enough with Grails, have to admit that I can't name any stunning change of core features since 1.20 to 1.3.7 - and in 1.4 roadmap too.

[ubiquibacon]

NetBeans or IntelliJ are the IDEs of choice for Grails. IntelliJ if you have the money.

[railsdog]

Rails for 5 years, Groovy/Grails for 8 months. Familiarity says Rails is better, but Grails is eminently usable once you're over the initial learning hump. Grails feels a little config file happy in comparison (do I really need 6 or 7 for a single plugin module?), but the persistence layer is very nice to work with. As for IDEs, used STS for 4 months with many frustrations, then tried IntelliJ for 4 days, and never looked back.

[Xorlev]

Grails is bloated for APIs, which is what I'd say for Rails too. For a general web application, it's hard to beat in terms of up and running with a full Java stack application behind you.

[Kapil Gund]

I just discovered your answer now. Great answer. Very objective.

[Nathan]

Which IDE are you using? I do not have a problem debugging with my IDE (IntelliJ).

[Andrey Chaschev]

It's Intellij and this debugging problem occurred among my colleagues. I had three projects with Grails in one we could not use debugging from Idea at all - it sort of caught on the first breakpoint, in two others there was no such problem, but there was a performance drop when viewing stack frame, so we debugged remotely.

[Andrey Chaschev]

I need to add that this is something which happens when you change your server code. It's all fine, when you do the JS/CSS/HTML thing.

[Nathan]

Are you actively using the test/unit/[your controllers] method? Just curious since my team also uses Intellij and we appreciate the tools for building and testing that Grails provides. I am not writing extensive use cases or scenarios though which could be a big difference.

[Andrey Chaschev]

Yes, I was more occupied with the back-end, less with the front-end. And all the Grails bugs I had were due to it's effort to recompile and reload Java server code while keeping JVM running.

[Andrey Chaschev]

And yes the best way to handle this was to Unit-test as much as possible to make sure you don't edit your code while instance is running.

[luisZavaleta]

Simon: unless you want to do some real time apps, performance is not a problem, yes it consume more RAM than a Java application but you can develop enterprise apps in half the time, so you save a lot of man-hours with the money you would spend in them you can pay a better server and you still saving lots of money.

[barrymac]

Akamai handles 98% of sky.com traffic. I will not speak about node uptime. I've switched to dropwizard. I still love groovy.

[Andrej Istomin]

> It is pretty straight-forward to learn, easy to develop, never saw anyone with a good knowledge of the Java world take more than a work week to know the basics. And then you spend months trying to fight Grails problems in production. Which are mostly caused by misusing almost all the tools they are trying to encapsulate under the hood. > Choose your IDE very carefully. Eclipse is shit, does anybody will clearly say that? :) > It is kind of heavy. yeah, the simple answer is no, it doesn't.