Is Grails (now) worth it?

问题

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.

回答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.

回答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

回答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.

回答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.

回答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.

回答6:

I have yet to find someone who is expert in both Grails and Rails and prefers Grails.

If you know both well, then you almost certainly prefer Rails.

Grails typically appeals to Java developers who fear platform change.

In this case, I think JRuby is probably a better way to adopt an agile approach on the aging legacy jvm.

回答7:

Having used Grails for a project recently I want to share our experiences compared to standard J2EE application development.

Does it really confer rapid development benefits?

Definitely, it does. Even if the scaffolding path is left early and conventions are overriden to the own needs, the start-up period is very short, as we don't have to care for many different technologies. That kind of lightweightness makes us work not only faster, but also more precise and clean.

Writing tags was never easier - while with JSF we first deliberate about whether it's worth the effort, with Grails we just do it. To work testdriven and to achieve a high coverage rate is also made quite easy, although the different test cases and mocking strategies are sometimes inconsistent and buggy.

Switching from Java to Groovy is a great pleasure, we loved to have list and map literals, closures, builders, to throw away our boiler plate "map" implementation in Java and to write compact, meaningful and focused code.

What slows down the development speed is the not so perfect IDE-support, which also holds true for the IntelliJ plugin, that we use. The bad, often old and even wrong documentation scattered over different places (foiling the promise "the search is over") gets also in the way of rapid development. So we often had to fall back to source code reading - subsequently being scared by the underlying Spring class hierarchies.

回答8:

Debugging is really hard. I've never found this to be a big problem. You can either attach a debugger and walk through, or stick a load of println/logs into the code to work out whats going on.

Logging is frankly awful. I agree the stack traces generally provide 4 pages of useless info, with the occasional line thats informative. However its a small price to pay for such an awesome framework.

The STS Eclipse IDE is of marginal value. Eclipse has piss poor support for Grails. Use IntelliJ if feasably possible. I am a tightwad, but if my company allowed me I would gladly pay the cash for IntelliJ.

回答9:

I've been using Grails since the very early 1.0-beta days and I can only recommend you start taking Groovy/Grails seriously if you come from Java shop.

If you are a Java shop and considering Ruby Rails, stop -- go Grails. If grails doesn't work for you then you can always start Rails.

回答10:

I'll share my 3-years experience using Grails in almost ten applications. I can't compare against Ruby on Rails so I'll answer your other questions.

Has it overcome its buggy start?

Yes it has. I've experienced a few Grails bugs on Grails 2.0.4/2.2.4.

Does it really confer rapid development benefits?

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. Also easy to maintain. And you don't have to worry about your DB a lot - just make sure your're mak

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

Choose your IDE very carefully. Eclipse helped me a lot but it crashes and causes more trouble than it should. I went for IntelliJ and in the trial month it seemed a better choice. Lately I've been using Sublime Text, a few plugins and the old command line. I only go to a IDE in special situations - to use its debugger, for example.

Does it perform for real world production apps?

It is kind of heavy. Research a lot on your design choices BEFORE writing your models. Do lots of research about good Grails design. Most of the things I've done two years ago I can realize how to make it better now since I'm more experienced. It handles real world production apps well but depending on the mistakes you make Hibernate can really be a headache.

回答11:

The Grails Eclipse plugin is crap. It crashes for no reason at all, and doesn't really support Groovy's flexibility. NetBeans and IntelliJ are rumoured to be much better, but I haven't tried them yet.

Does it perform? Of course it does. Even Ruby on Rails performs, as long as you throw enough servers at the problem. I have no idea how Grails compares to various Java frameworks, though.

Does it really confer rapid development benefits? Well, I'm still missing a lot of good Ruby/Rails stuff. It doesn't recognise Date and Enum request params automatically (then again, Rails also has some issues with Dates), TimeCategory should be part of the standard configuration but isn't. But there's also a lot of stuff that requires remarkably little configuration.

It's not quite where Rails is (I'm particularly looking forward to Rails 3), but it's a lot more pleasant to work with than many Java frameworks. Even so, the magic below the surface goes way deeper than in Rails. For example, the system for Constraints is really powerful, but built on top of a huge layer of impenetrable Spring stuff, and really inflexible if you want to use that same power in a slightly different way. Rails is easier to subvert, IME.

Is it worth it? Yes. Is it a better choice than something else? That depends.

回答12:

I would suggest you try for yourself. I love the flexibility of Grails and the Development Speed. However as you can see other people's experience differs. I want to be able to develop rapid applications for my clients using the Java Platform and I have found Grails to work very well for us.

I have also found the frontend very flexible to develop. I also think you need to use common sense and choose your plugin's carefully. I stick to the plugins supported by springsource.

回答13:

In my experience, Grails bring a few very attractive features on the table which definitely makes worth learning and using it.

Agility - things we used to take weeks to implement in conventional J2EE projects are generally a day's work with grails plugin system. Things like ajax, jquery ui, acegi, restful implementation, scheduler system and lots of them
Runs on JVM which alleviates need to learn some other run time system and its idiosyncracies
Java like syntax and groovy syntax sugar. like best of both the worlds. You can immediately start with Java instead of learning syntax of new language like Ruby and then slowly you can move to groovy syntax which is robust, easy and intuitive

For the project managers, unless there is compelling reason for "not to use" grails for some reason( resistance from higher up, to adopt new technology or something), I don't see any reason why grails can't be used or at least tried.

To answer the concern about debugging, it's not that hard. Debugging is easy if you use Netbeans IDE. That brings me to one more point to mention. After few experiments with all the IDEs we found that Netbeans is the most suited to do the job. It has better support for code completion, syntax highlighting and debugging etc. In my opinion, STS is not good enough for that.

回答14:

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

It had definitly improved a lot over the last year. In Dec I attended the Groovy&Grails Exchange in London. There was a great talk regarding the Groovy&Grails integration in Eclipse/SpringSource STS that has been recorded, see the video.

From my point of view, Eclipse gained a lot of ground. Currently IntelliJ seems to be a slight bit ahead but that might change within the next few months.

回答15:

Regarding the eclipse plugin, is still coming its way, but you can use the eclipse version from Spring Source (SpringSource Tool Suite)

http://www.springsource.com/products/sts

It's quite decent compared to the previous plugin versions, and since Spring Source has acquired the company responsible for grails and groovy, you can expect that STS will become better quickly

回答16:

Personally, I learnt RoR and used it for a few home projects, but then switched to Grails, mostly because it runs on the JVM and therefore I am hoping to make use of the plethora of Java performance/profiling programs, which should help identify any bottlenecks in code before they become a problem.

In general I haven't found too much difference in the quality of IDE's used by RoR vs Grails. Although, to be fair, I'm programming on Linux and haven't tried TextMate for RoR development. When I was using RoR I used Netbeans.

Right now I am programming using STS and am finding it a pleasure to use with Grails, although I still find that method detection/completion could be made to work much better.

回答17:

I'm a full time java developer but use rails for my hobby projects. We evaluated grails for a project at work a year back. My experience with grails left me feeling a bit disappointed and this was the reason that I began to investigate rails. Having used both my impression is that even though groovy is not far behind ruby as a language, rails provides a significantly improved experience over grails. Quite simply, rails seems to solve far more real world problems, particularly when you factor in the number of good gems that are available. I'm thinking of things like, providing search, versioning, rss, non crud apps, integration with cloud services, etc. I get the impression that grails is around about the level of rails 1.x. By the end of this month rails 3 should have been released. We've actually decided to now move towards using rails at work. In the end, grails is easier to pick up for java developers, but ultimately lacks the refinement to cover a wider range of project requirements.

回答18:

I would say no. It is too still bloated, imho, for most uses, especially if you just want to prototype something. We don't need all of that code, all those dependencies bundled with grails in order to make a web application. You don't need spring every single time you want to put out a web application. Look at what you are trying to accomplish before you add a whole world full of dependencies to your stack. I think it's important to know what your application comprises of.

I recommend looking at something like ratpack, which is much lighter, almost like sinatra for ruby.

回答19:

I want to point out to two more considerations, memory usage and job market. Grails application takes a lot of memory especially in development mode e.g. 600 Mb for a medium sized application. When deployed in production mode, e.g. war file in Tomcat, the usage can be about 500 Mb. This is partly inherited from using Java.

As for job market and as far as I have read, there is little demand for Grails programmers in job vacancy announcements compared to e.g. Django and Ruby on Rails.

回答20:

From my experience as of end of 2013.

Pros

when you use very little of the plugins and confine a set of Grails no-s and never-s, it's quite a smooth developing experience

Cons

Refreshing (F5) is always a problem. And this is the most annoying. For some reason I had to restart the server on each 3rd-4th refresh. There is a well-known restart bug: question1, question2, though it happens rarely.
Language-level bugs. When I used static inner classes, I always needed to restart the server on a change. Though there are no problems with building, language usage is limited for me
startup time, build time, application size (70 megs for a small app), memory usage
remote debugging only, IDE debugging is very unstable

回答21:

Has it overcome its buggy start?

It's still horrible. I do not know their start, but migration from Grails 2 to Grails 3 is still nightmare and they are breaking more than they solve.

Does it really confer rapid development benefits?

I spent one hour making Grails' tests to output something in console(it doesn't work out of the box), even in Java you will not spend such amount of time to output something from tests.