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.
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
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.
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.
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.
拖慢开发速度的是不太完善的 IDE 支持，这对于我们使用的 IntelliJ 插件也是如此。分散在不同地方的糟糕的、通常是旧的甚至错误的文档（违背了“搜索结束”的承诺）也会阻碍快速开发。因此，我们经常不得不退回到源代码阅读 - 随后被底层的 Spring 类层次结构吓坏了。
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.
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.
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.
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.
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.
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.
要回答有关调试的问题，并不难。如果使用 Netbeans IDE，调试会很容易。这让我还有一点要提。经过对所有 IDE 的几次实验，我们发现 Netbeans 最适合完成这项工作。它对代码补全、语法高亮和调试等有更好的支持。在我看来，STS 对此还不够好。
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.
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.
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
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.
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.
我会说不。恕我直言，对于大多数用途来说，它仍然太臃肿了，特别是如果你只是想制作原型。我们不需要所有的代码、所有与 grails 捆绑在一起的依赖项来创建一个 Web 应用程序。您不需要每次想要推出 Web 应用程序时都需要 Spring。在将充满依赖项的整个世界添加到堆栈之前，先看看您想要完成什么。我认为了解您的应用程序包含哪些内容很重要。
我建议看看ratpack之类的东西，它要轻得多，几乎就像sinatra for ruby一样。
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.
至于就业市场，据我所知，与 Django 和 Ruby on Rails 等相比，职位空缺公告中对 Grails 程序员的需求很少。
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.
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
如果您买不起 Microsoft Access 许可证，也许可以。对于真正的项目，我会远离 Grails。事实上，这只是一个死产。
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.
Does it perform for real world production apps?
I still do not know a single famous company who is building something with Grails.
Is the Eclipse plug-in better than it was and fit for purpose?
I've no idea why anybody's still using Eclipse, but IntelliJ support for Grails 3 is just unusable.
So, answering the main question:
Is Grails (now) worth it?
If you can not afford the Microsoft Access license, maybe. For real projects I would stay away from Grails. It's just a stillborn child, in fact.
发布评论
评论（21）
我使用 Grails 已有 4 个多月了，我将尽力向您介绍我对 Grails 及其可用性的个人感受。
当然，答案不是“是”或“否”，而是视情况而定。这取决于您的需求（您需要在Java世界中吗？），也取决于您的偏好（您更喜欢面向领域的开发，您更喜欢Groovy...）？
不过，我可以回答说，Grails 是 Rails 的一个重要替代品。我相信无论您的 Rails 应用程序是什么，您都可以使用 Grails 来完成。但根据项目的性质，可能需要更多或更少的时间。再次强调，如果您熟悉 Rails 但不熟悉 Grails，那么 Rails 是更安全的选择。
是。如果你看一下我最初的消息（在这个网站或其他网站），我抱怨了很多关于 Grails 的错误。但是，您只需要记住，Grails 的边缘有点粗糙（例如，没有太多使用域继承），一旦您熟悉了该框架，您就不会遇到太多糟糕的意外。我并不是说 Grails 没有 bug。它肯定比 Rails 更重要。而且，它比越野车更有用。对此的一条建议是：使用尽可能少的插件。因为它们中的许多都是有缺陷的，并且有些彼此之间不兼容。因此，不要包含 grails 插件，除非您确定 grails 插件是最新的、非侵入性的并且经过测试（由您自己）。
是。您几乎不需要处理数据库设计。由于约定优于配置，配置几乎从一开始就为您完成。您的应用程序很容易维护。我看到的唯一缺点是前端开发不如其他技术（如 Rails 或 ASP）丰富
我不能这么说，因为我还没有上线我的网站，但我非常有信心，因为 sky.com 正在使用 Grails 并且这些网站吸引了大量流量 - 周围
每天 700 万次页面浏览量。同样，性能在很大程度上取决于您的应用程序架构和设计决策。
不知道。我正在使用 IntelliJ，但根据我在 Grails 领域看到的抱怨消息，我猜它并不比一年前好多少。
我希望它有帮助。
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.
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.
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).
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)
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.
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.
最近开始了一个 Rails 项目，一直在用 Grails 做一些事情。
我对 Rails 的主要看法是，有很多东西对开发人员来说是完全不透明的（我讨厌这一点），当你开始添加更多插件/生成器时，这种情况往往会增加。 libs/etc，因为为了组合它们，您需要修补一些东西。您会感觉rails+plugins只是一个巨大的DSL hack，如果您使用插件+版本的错误组合，它就会开始崩溃。
使用 Grails，虽然生态系统要小得多，但一切都趋于相对一致。 DSL 方法不太常用，通过使用传统但无聊设计（我的意思是使用类、接口等而不是 DSL），可以更容易地理解管道的工作原理。
进行一对一的比较，情况如下：
Grails 拥有出色的基础插件（授权/身份验证、ORM 等）以及一些其他用于较小内容的插件
这是一个例子：
结论：
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:
Grails has excellent plugins for the basics (authorization/authentication, ORM, etc) and some other plugins for smaller stuff
Here's an example:
Conclusion:
非常值得！
我们在多个项目中使用 Grails，所有项目都取得了巨大成功，原因如下：
Easy - 这是我们用过的最简单的框架之一
遗留代码重用 - 我们所要做的就是获取遗留代码并将其放入 lib 或 src 文件夹中，然后就完成了。对我们来说太棒了。
旧数据库结构 - 如果您想在旧数据库上生成数据可视化，这是一个很棒的工具。
现在，关于可行性：
错误：自版本 1.1 以来，我们没有遇到太多错误（版本 1.0 对我们来说错误太多）
工具：Netbeans 在这方面确实有所改进，但它甚至还没有接近其他工具，如 Intellij IDEA（大力支持！）。 Eclipse 也是如此。
可移植性：我们的项目从未遇到过任何问题。
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.
我们现在有六个 Grails 应用程序投入生产，虽然 Grails 与 java 框架不同并且需要一些学习时间，但它已经得到了回报，因为我们使用了敏捷技术。详细信息：
这就是说，与所有新技术一样，我建议制作原型、代码审查、结对编程，也许还可以使用一些咨询。
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:
This said, as with all new technologies, I recommend making prototypes, code reviews, pair programming, and maybe use some consulting as well.
这是非常值得的。我已经使用它一年多了并且非常喜欢它。我曾经回避这些类型的 rad 工具，但它改变了我的工作方式。在 1.2 版本中，它变得更好，具有更好的堆栈跟踪信息（特别是对于 GSP）。
我在扩展方面遇到的唯一问题是休眠及其缓存，这实际上不是 Grails 问题。即使那些我一般不喜欢 hibernate 的人，grails 用 GORM 包装它的方式对我来说也是一件艺术品。标准封闭方面的合作非常好。
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.
我还没有找到既精通 Grails 又精通 Rails 并且更喜欢 Grails 的人。
如果您对两者都很了解，那么您几乎肯定会更喜欢 Rails。
Grails 通常吸引那些担心平台变化的 Java 开发人员。
在这种情况下，我认为 JRuby 可能是在老化的遗留 jvm 上采用敏捷方法的更好方法。
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.
最近在一个项目中使用了 Grails，我想分享一下我们与标准 J2EE 应用程序开发相比的经验。
确实如此。即使很早就留下了脚手架路径，并根据自己的需求重写了约定，启动时间也很短，因为我们不必关心许多不同的技术。这种轻便性使我们的工作不仅更快，而且更加精确和干净。
编写标签从未如此简单 - 对于 JSF，我们首先考虑是否值得付出努力，而对于 Grails，我们就这样做。尽管不同的测试用例和模拟策略有时不一致且存在错误，但测试驱动的工作和实现高覆盖率也变得相当容易。
从 Java 切换到 Groovy 是一种极大的乐趣，我们喜欢拥有列表和映射文字、闭包、构建器，抛弃 Java 中的样板“映射”实现，并编写紧凑、有意义且专注的代码。
拖慢开发速度的是不太完善的 IDE 支持，这对于我们使用的 IntelliJ 插件也是如此。分散在不同地方的糟糕的、通常是旧的甚至错误的文档（违背了“搜索结束”的承诺）也会阻碍快速开发。因此，我们经常不得不退回到源代码阅读 - 随后被底层的 Spring 类层次结构吓坏了。
Having used Grails for a project recently I want to share our experiences compared to standard J2EE application development.
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.
我将分享我 3 年在近 10 个应用程序中使用 Grails 的经验。我无法与 Ruby on Rails 进行比较，因此我将回答您的其他问题。
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.
调试真的很难。
我从来没有发现这是一个大问题。您可以附加一个调试器并逐步执行，或者将大量 println/logs 粘贴到代码中以了解发生了什么。
坦率地说，日志记录很糟糕。
我同意堆栈跟踪通常提供 4 页无用信息，其中偶尔会提供一些信息。然而，为如此出色的框架付出的代价很小。
STS Eclipse IDE 的价值微乎其微。
Eclipse 对 Grails 的支持非常差。如果可行，请使用 IntelliJ。我是个吝啬鬼，但如果我的公司允许我，我很乐意为 IntelliJ 支付现金。
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.
我从 1.0-beta 早期就开始使用 Grails，如果您来自 Java 商店，我只能建议您开始认真对待 Groovy/Grails。
如果您是一家 Java 商店并且考虑使用 Ruby Rails，请停止使用 Grails。如果 grails 不适合您，那么您可以随时启动 Rails。
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.
Grails Eclipse 插件很糟糕。它会无缘无故地崩溃，并且并不真正支持 Groovy 的灵活性。据传 NetBeans 和 IntelliJ 更好，但我还没有尝试过。
它有表现吗？当然可以。只要您投入足够的服务器来解决问题，即使 Ruby on Rails 也能发挥作用。不过，我不知道 Grails 与各种 Java 框架相比如何。
它真的能带来快速发展的好处吗？好吧，我仍然缺少很多 Ruby/Rails 的好东西。它不能自动识别 Date 和 Enum 请求参数（再说一次，Rails 也有一些关于日期的问题），TimeCategory 应该是标准配置的一部分，但事实并非如此。但也有很多东西只需要很少的配置。
它与 Rails 不太一样（我特别期待 Rails 3），但它比许多 Java 框架使用起来要愉快得多。即便如此，表面之下的魔力比 Rails 还要深刻得多。例如，Constraints 系统非常强大，但是构建在一大层难以理解的 Spring 东西之上，如果您想以稍微不同的方式使用相同的功能，则非常不灵活。 Rails 更容易颠覆，IME。
值得吗？是的。这是比其他更好的选择吗？这要看情况。
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.
我建议你自己尝试一下。我喜欢 Grails 的灵活性和开发速度。然而，正如您所看到的，其他人的经历有所不同。我希望能够使用 Java 平台为我的客户开发快速应用程序，并且我发现 Grails 非常适合我们。
我还发现前端的开发非常灵活。我还认为您需要运用常识并仔细选择插件。我坚持使用 springsource 支持的插件。
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.
根据我的经验，Grails 带来了一些非常有吸引力的功能，这绝对值得学习和使用它。
Java 类似语法和 groovy 语法糖。两全其美。您可以立即开始使用 Java，而不是学习 Ruby 等新语言的语法，然后慢慢地转向健壮、简单且直观的 Groovy 语法
对于项目经理来说，除非有令人信服的理由“不使用”grails（来自高层的抵制、采用新技术或其他什么），我不认为有任何理由不能使用 grails。使用过或至少尝试过。
要回答有关调试的问题，并不难。如果使用 Netbeans IDE，调试会很容易。这让我还有一点要提。经过对所有 IDE 的几次实验，我们发现 Netbeans 最适合完成这项工作。它对代码补全、语法高亮和调试等有更好的支持。在我看来，STS 对此还不够好。
In my experience, Grails bring a few very attractive features on the table which definitely makes worth learning and using it.
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.
与去年相比，它确实有了很大的进步。 12 月，我参加了伦敦的 Groovy&Grails Exchange。有一篇关于 Eclipse/SpringSource STS 中的 Groovy&Grails 集成的精彩演讲已被记录，请参阅 视频。
从我的角度来看，Eclipse 取得了很大的进展。目前，IntelliJ 似乎稍微领先一些，但这种情况可能会在未来几个月内发生变化。
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.
关于 eclipse 插件，仍在开发中，但您可以使用 Spring Source (SpringSource Tool Suite) 的 eclipse 版本
http://www.springsource.com/products/sts
与之前的插件版本相比已经相当不错了，而且由于 Spring Source 已经收购了负责 grails 和 groovy 的公司，所以可以预期 STS 将成为快点好起来
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
就我个人而言，我学习了 RoR 并将其用于一些家庭项目，但后来转向了 Grails，主要是因为它在 JVM 上运行，因此我希望利用大量的 Java 性能/分析程序，这应该有助于识别任何在代码瓶颈成为问题之前就解决它们。
总的来说，我没有发现 RoR 与 Grails 使用的 IDE 的质量有太大差异。不过，公平地说，我是在 Linux 上编程，还没有尝试过使用 TextMate 进行 RoR 开发。当我使用 RoR 时，我使用 Netbeans。
现在我正在使用 STS 进行编程，并且发现与 Grails 一起使用是一种乐趣，尽管我仍然发现方法检测/完成可以做得更好。
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.
我是一名全职 Java 开发人员，但使用 Rails 来完成我的爱好项目。我们在一年前的一个工作项目中评估了 grails。我使用 grails 的经历让我感到有点失望，这就是我开始研究 Rails 的原因。使用过这两种语言后，我的印象是，尽管 groovy 作为一种语言并不落后于 ruby，但与 grails 相比，rails 提供了显着改进的体验。很简单，rails 似乎可以解决更多现实世界的问题，特别是当您考虑到可用的优质宝石的数量时。我正在考虑诸如提供搜索、版本控制、RSS、非 CRUD 应用程序、与云服务集成等。
我的印象是 grails 的水平大约是 Rails 1.x 的水平。到本月底，rails 3 应该已经发布了。实际上，我们现在已经决定在工作中使用 Rails。最后，Grails 对于 Java 开发人员来说更容易上手，但最终缺乏满足更广泛项目需求的改进。
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.
我会说不。恕我直言，对于大多数用途来说，它仍然太臃肿了，特别是如果你只是想制作原型。我们不需要所有的代码、所有与 grails 捆绑在一起的依赖项来创建一个 Web 应用程序。您不需要每次想要推出 Web 应用程序时都需要 Spring。在将充满依赖项的整个世界添加到堆栈之前，先看看您想要完成什么。我认为了解您的应用程序包含哪些内容很重要。
我建议看看ratpack之类的东西，它要轻得多，几乎就像sinatra for ruby一样。
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.
我想指出另外两个考虑因素：内存使用和就业市场。 Grails 应用程序需要大量内存，尤其是在开发模式下，例如中型应用程序需要 600 Mb。当部署在生产模式下时，例如Tomcat 中的war 文件，使用量约为500 Mb。这部分是从使用 Java 继承的。
至于就业市场，据我所知，与 Django 和 Ruby on Rails 等相比，职位空缺公告中对 Grails 程序员的需求很少。
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.
根据我截至 2013 年底的经验。
优点是，
缺点
From my experience as of end of 2013.
Pros
Cons
仍然很可怕。我不知道他们是从哪里开始的，但是从 Grails 2 迁移到 Grails 3 仍然是一场噩梦，而且他们带来的破坏比解决的还要多。
我花了一个小时进行 Grails 测试以在控制台中输出一些内容（它不能开箱即用），即使在 Java 中，您也不会花这么多时间从测试中输出一些内容。
我还不知道哪一家著名公司正在使用 Grails 构建某些东西。
我不知道为什么还有人还在使用 Eclipse，但 IntelliJ 对 Grails 3 的支持根本无法使用。
那么，回答主要问题：
如果您买不起 Microsoft Access 许可证，也许可以。对于真正的项目，我会远离 Grails。事实上，这只是一个死产。
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.
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.
I still do not know a single famous company who is building something with Grails.
I've no idea why anybody's still using Eclipse, but IntelliJ support for Grails 3 is just unusable.
So, answering the main question:
If you can not afford the Microsoft Access license, maybe. For real projects I would stay away from Grails. It's just a stillborn child, in fact.