Grails vs Rails—我的想法

在我的blog的最近的一次评论中，Jared Peterson问道： 我想知道你关于在Rails和Grails之间做一个选择的所有想法。虽然我喜欢“允许他们两个一起（发展）”的理论，但是你的“一个也不要”是什么意思？ 如果你开发了一个新的项目，会选择其中的一个吗？需要和很多已经存在的Java代码（这里的Rails，我猜是指JRuby on Rails）交互，你会选择什么呢？ 同时，最近有一个朋友问我，“我想知道您关于Grails的诚实的、正直不带倾向性的观点？”我想我发给这个朋友的e-mail可以对Jared的问题有帮助。 我想它至少是让人尊敬的。它的竞争者像AppFuse，但是它有更加容易学习和记住的DSL。更少的代码，更高的效率。虽然看起来有些成熟度的问题，但我想它迟早会解决。问题是——Groovy语言的发展会有多快。这就像Rails和Ruby之间的关系。所以，当你开始使用Grails的时候，你就会想到，“Groovy语言好酷啊，我喜欢学习更多有关它的知识”。我喜欢Groovy语言的一个原因是对于资深的开源Java开发人员，Groovy语言的学习曲线实际上相当的平缓。您只需要一天就能学习到可以开发工作的程度。 这就是说，我认为有一系列的相当酷的工具来开发RIA。IMO、Flex或者GWT+Grails对于开发来说是一系列相当有趣的工具。这里有我最近写的关于分析Rails和Grails的一些引用： 比较Rails和Grails 它们都是优秀的开发架构。Rails更加成熟一些，但是创建环境是相当痛苦的（特别是在Windows上）。对于Java开发人员来说，Grails非常容易创建起来。Grails需要提高的地方是热发布和出错记录堆栈，但这些大概是Groovy语言的问题，出错记录堆栈是惨不忍睹的—很少在最初的几行指出类和行数。 对于热发布，Grails也没有Rails做得好。Rails的“script/server”启动WEB应用只需要几秒钟，而“grails run-app”则需要十几秒钟（即使是一个新的没有内容的应用）。即使是这样，Grails仍然是令人尊敬的。我真的、真的喜欢在IDEA里写Groovy代码，并且看到及时的改变。我不喜欢“test-app”以及Rails的“test:units”（也不喜欢“test:uncommitted”）。这些都被广泛的认为是Rails拥有一个好的测试的原因。 现在，Rails是可用的，而Grails是70%可用的。 对于Java开发人员来说，Groovy语言是非常容易学的。Ruby也容易学习，并且对于OO开发人员来说，也相当强大。两者都有编程的乐趣，并且有能力大大提高开发效率。如果你熟悉Hibernate、Spring、SiteMesh和JSP，那么你应该学习Grails。如果你精通这些技术，那么你一个小时之内就能学会Grails。你会在下一个小时大大提高生产力，并且在这一天结束的时候，你就会一个应用跑起来。这没有把任何的东西从Ruby拿开。我相信Rails也是一个优异的平台。它相当的酷，profiling和benchmarking内建在开发框架里，你可以轻松的判断你需要多少服务器的规模。 我使用IDEA来在这两种开发框架上做开发。通过插件，IDEA有Rails和Groovy的支持，而且它们都运行的不错。但是对于Grails的支持比对于Rails地支持要好。Grails提供代码完整、在类和方法上的Ctrl+点击，debugging和在IDE里开启/关闭应用。Rails不能提供在类和方法上的Ctrl+点击和debugging。 有没有Rails能做而Grails不能做的事情？这就不是我能够告诉你的。我想这取决于开发人员的热情和开发团队的选择。如果你是资深的Java开发人员并且喜欢这个生态和它的工具，那么选择Grails就更直观一些。如果你是资深的PHP开发人员或者在J2EE上感觉不好，那么你可能更喜欢Rails一些。对于两个开发框架来说，它们都有一个相同的事情——学习一个实际上会教给你另一个的知识。它们在很多方面都如此相似，以至它们之间的知识可以相互转移。 当然，这些都只是我使用这个两个开发框架工作了几周以后的一些观点。对于那些同时使用过这两个架构的人来说，你们是怎么想的呢？ 最后，这里有一个在Javalobby上关于最近评论的引用： 当然，现在的难题是决定选择Django,Rails,Grails和GWT作为你的开发框架。然后，你不得不选择Ferrari,Porsche,Lamborghini 和 a Maserati。无论你选什么，它都不会使你失望。