Comments on: Grails Vs. Rails – the Thrilla in Manila: A Study on Platform Productivity http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/ Results through imagination Mon, 15 Mar 2010 02:56:23 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: JS Bournival » Blog Archive » Groovy + Grails: le vent en poupe http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/comment-page-1/#comment-8091 JS Bournival » Blog Archive » Groovy + Grails: le vent en poupe Mon, 05 Nov 2007 18:43:58 +0000 http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/#comment-8091 [...] À commencer par cet article, qui démontre la productivité acquise par l’utilisation de Grails par rapport à d’autres stack techniques. Même Rails en prend pour son rhume. À savoir maintenant si la véracité des chiffres avancé est bien réelle, c’est une autre histoire. Mais tout ceci me semble plausible au premier coup d’oeil. [...] [...] À commencer par cet article, qui démontre la productivité acquise par l’utilisation de Grails par rapport à d’autres stack techniques. Même Rails en prend pour son rhume. À savoir maintenant si la véracité des chiffres avancé est bien réelle, c’est une autre histoire. Mais tout ceci me semble plausible au premier coup d’oeil. [...]

]]> By: Blog do Márcio d’Ávila » Uma plataforma para as outras dominar http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/comment-page-1/#comment-6226 Blog do Márcio d’Ávila » Uma plataforma para as outras dominar Thu, 09 Aug 2007 04:26:51 +0000 http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/#comment-6226 [...] Coincidentemente, produtividade de frameworks é o tema de outro artigo no Javalloby, Is Grails More Productive than Rails?, que referencia a pesquisa da consultoria AlterThought, que estimou e comparou o esforço de desenvolvimento de um projeto em J2EE, Java/Spring, Rails e Grails. Na avaliação, o framework de aplicações web Grails, baseado na linguagem de programação Groovy e Java, se mostrou o mais produtivo. [...] [...] Coincidentemente, produtividade de frameworks é o tema de outro artigo no Javalloby, Is Grails More Productive than Rails?, que referencia a pesquisa da consultoria AlterThought, que estimou e comparou o esforço de desenvolvimento de um projeto em J2EE, Java/Spring, Rails e Grails. Na avaliação, o framework de aplicações web Grails, baseado na linguagem de programação Groovy e Java, se mostrou o mais produtivo. [...]

]]> By: Ivan http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/comment-page-1/#comment-6200 Ivan Mon, 06 Aug 2007 17:33:26 +0000 http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/#comment-6200 If he has to qualify that everything he says is written by a Java dev, then every frickin article written by DHH should post the exact same bias. While article at least *TRIES* to be factual DHH just says Java takes 10 times as much PERIOD without a hint of how he came to that conclusion. So the RoR camp is pissed at what they perceive as baseless productivity claims?!?! WOW. The irony is delicious. If he has to qualify that everything he says is written by a Java dev, then every frickin article written by DHH should post the exact same bias. While article at least *TRIES* to be factual DHH just says Java takes 10 times as much PERIOD without a hint of how he came to that conclusion.

So the RoR camp is pissed at what they perceive as baseless productivity claims?!?! WOW. The irony is delicious.

]]> By: Manohar http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/comment-page-1/#comment-6194 Manohar Mon, 06 Aug 2007 01:33:34 +0000 http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/#comment-6194 I'm actually surprised by the very strong opinions expressed in some of the comments. The comment about having a contest to determine which one is better is really kid-ish. I certainly agree that RoR is a great framework, but guys, don't get agitated if you learn that a java application development could offer similar productivity levels. It is an established fact that JEE application provides the robustness and performance levels required for enterprise development. The only think lacking was RAD and productivity. Grails does this very well. I think the message from this post is - It is possible to to develop an enterprise JEE application with productivity levels matching RoR. End of story. I’m actually surprised by the very strong opinions expressed in some of the comments. The comment about having a contest to determine which one is better is really kid-ish. I certainly agree that RoR is a great framework, but guys, don’t get agitated if you learn that a java
application development could offer similar productivity levels.

It is an established fact that JEE application provides the robustness and performance levels required for enterprise development. The only think lacking was RAD and productivity. Grails does this very well.

I think the message from this post is – It is possible to to develop an enterprise JEE application with productivity levels matching RoR. End of story.

]]> By: Ryan http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/comment-page-1/#comment-6188 Ryan Sat, 04 Aug 2007 20:00:40 +0000 http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/#comment-6188 Did you evaluate Wicket? The productivity level is about the same as Grails but the code is more maintainable and there's no additional language involved. It's not a "full-stack" framework, but you can of course use Hibernate directly or, if you have more modest ORM needs, you can't bean Cayenne for productivity. Wicket's main advantage over Grails is its component-oriented architecture, which allows for more code reuse than any other web framework (including other component-oriented frameworks such as Tapestry). The powerful and amazingly simple Ajax support in Wicket is also second-to-none and its plain HTML templates keep all your logic where it belongs: in pure Java code. Anyway, I think Wicket would have easily "won" your evaluation had it been on your list. Did you evaluate Wicket? The productivity level is about the same as Grails but the code is more maintainable and there’s no additional language involved. It’s not a “full-stack” framework, but you can of course use Hibernate directly or, if you have more modest ORM needs, you can’t bean Cayenne for productivity.

Wicket’s main advantage over Grails is its component-oriented architecture, which allows for more code reuse than any other web framework (including other component-oriented frameworks such as Tapestry).

The powerful and amazingly simple Ajax support in Wicket is also second-to-none and its plain HTML templates keep all your logic where it belongs: in pure Java code.

Anyway, I think Wicket would have easily “won” your evaluation had it been on your list.

]]> By: sunjay http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/comment-page-1/#comment-6186 sunjay Sat, 04 Aug 2007 03:24:02 +0000 http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/#comment-6186 @ "estimate versus actual" criticism .. yes, on the surface it appears flawed to compare a Grails 'actual' to an "X" technology estimate .. to that, I offer a snippet from a previous post (complimentary of Rails -- 7 days into the start of our Grails measurement initiative): " Obligatory Caveat: While we’ve not built the same application in a variety of langugages to assess the potential savings, we have normalized by analyzing applications of similar complexity with comparable team competencies (using Planix as our steward). To cut to the chase, in general the economics and adaptability of a Rails-based application versus other applications look something like this –" http://alterlabs.com/technologies/java/revenue-on-ruby-on-rails/ @ “estimate versus actual” criticism .. yes, on the surface it appears flawed to compare a Grails ‘actual’ to an “X” technology estimate .. to that, I offer a snippet from a previous post (complimentary of Rails — 7 days into the start of our Grails measurement initiative):

” Obligatory Caveat: While we’ve not built the same application in a variety of langugages to assess the potential savings, we have normalized by analyzing applications of similar complexity with comparable team competencies (using Planix as our steward).

To cut to the chase, in general the economics and adaptability of a Rails-based application versus other applications look something like this –”

http://alterlabs.com/technologies/java/revenue-on-ruby-on-rails/

]]> By: CG http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/comment-page-1/#comment-6184 CG Fri, 03 Aug 2007 22:39:28 +0000 http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/#comment-6184 @Steven Devijver It is not obvious, but I am actually thanking you for creating Grails because if I am forced to do another Java based web application I will run rather than walk to use it. It has to be a lot better than the Servlet / JSP / multiple other sub-framework based alternatives and configuration files. I needed a library of about a dozen books just create a single mid sized web application. @Steven Devijver

It is not obvious, but I am actually thanking you for creating Grails because if I am forced to do another Java based web application I will run rather than walk to use it.

It has to be a lot better than the Servlet / JSP / multiple other sub-framework based alternatives and configuration files. I needed a library of about a dozen books just create a single mid sized web application.

]]> By: CG http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/comment-page-1/#comment-6183 CG Fri, 03 Aug 2007 22:26:14 +0000 http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/#comment-6183 Well not only have I started using Java but have used it (had to) for over 5 years so it is a good thing that someone is doing something about the complexity and configuration proliferation in Java. I will say that it sucked most of the joy out of programming for me until RoR came along. Now if you really want a catchy blog title try "From Java to the Holy Grail" - maybe you have created the savior after all - or maybe that title goes to jRuby - hmmmm I guess I'll let you guys duke it out on that one. So as you admit to not yet starting to use RoR, how can you state it is hardly a standard to compare things against. Actually whether it is or not it is a standard to compare against, it seems that everybody feels compelled to compare their new baby against it, and create their own flavor of it, like jRuby, IronRuby, Grails, and more to come I'm sure. Again I think a contest could put all this my baby is better then your baby stuff to rest. I also think it is inevitable that such a contest will take place within the next year or two. Perhaps the clear winner down the road will be the language/framework that allows the quickest learning curve to get new unbiased programmers productive. I am pretty sure compiler and hardware improvements will make all performance issues moot - if not Java would not be popular today and history does repeat itself. Of course bad designs and algorithms at the software and database level are the real bottle necks which are easily created in any language/framework. Well not only have I started using Java but have used it (had to) for over 5 years so it is a good thing that someone is doing something about the complexity and configuration proliferation in Java. I will say that it sucked most of the joy out of programming for me until RoR came along. Now if you really want a catchy blog title try “From Java to the Holy Grail” – maybe you have created the savior after all – or maybe that title goes to jRuby – hmmmm I guess I’ll let you guys duke it out on that one.

So as you admit to not yet starting to use RoR, how can you state it is hardly a standard to compare things against. Actually whether it is or not it is a standard to compare against, it seems that everybody feels compelled to compare their new baby against it, and create their own flavor of it, like jRuby, IronRuby, Grails, and more to come I’m sure.

Again I think a contest could put all this my baby is better then your baby stuff to rest. I also think it is inevitable that such a contest will take place within the next year or two.

Perhaps the clear winner down the road will be the language/framework that allows the quickest learning curve to get new unbiased programmers productive. I am pretty sure compiler and hardware improvements will make all performance issues moot – if not Java would not be popular today and history does repeat itself. Of course bad designs and algorithms at the software and database level are the real bottle necks which are easily created in any language/framework.

]]> By: Ryan Daigle http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/comment-page-1/#comment-6182 Ryan Daigle Fri, 03 Aug 2007 22:09:47 +0000 http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/#comment-6182 @Sunjay: "We’ve see a fair number of clients start out in a <i>scripting language</i>.." I know you didn't just call Ruby a "scripting language"? Being a dynamically typed language and being a scripting language are two very different things. Ruby supports all of the language constructs, and more, of your statically typed Javas of the world. But, that small technical detail aside, I applaud you guys for exposing the internals of your operations and business decisions for all to see. Such a conversation, and not a flame war as some would like to start, benefits all involved! @Sunjay: “We’ve see a fair number of clients start out in a scripting language..”

I know you didn’t just call Ruby a “scripting language”?

Being a dynamically typed language and being a scripting language are two very different things. Ruby supports all of the language constructs, and more, of your statically typed Javas of the world.

But, that small technical detail aside, I applaud you guys for exposing the internals of your operations and business decisions for all to see. Such a conversation, and not a flame war as some would like to start, benefits all involved!

]]> By: Steven Devijver http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/comment-page-1/#comment-6180 Steven Devijver Fri, 03 Aug 2007 18:08:11 +0000 http://alterlabs.com/technologies/java/grails-vs-rails-the-thrilla-in-manilla-a-study-on-grails-productivity/#comment-6180 RoR is hardly a standard to compare anything to. As Grails co-founder I can say that the only RoR features we thought about were DRY and CoC, I have yet to start using RoR, personally I only know it from the screencast like most people I guess. The standard to match and out-perform was and still is Java/Spring/Hibernate/XML. This combo offers a lot of power (XA, JMS, JMX, AOP, consistency, lazy loading, remote access, ...) yet misses productivity. We started Grails because we thought we could improve Java/Spring/Hibernate/XML productivity while offering the same kind of integration and close to the same performance. RoR is hardly a standard to compare anything to. As Grails co-founder I can say that the only RoR features we thought about were DRY and CoC, I have yet to start using RoR, personally I only know it from the screencast like most people I guess.

The standard to match and out-perform was and still is Java/Spring/Hibernate/XML. This combo offers a lot of power (XA, JMS, JMX, AOP, consistency, lazy loading, remote access, …) yet misses productivity.

We started Grails because we thought we could improve Java/Spring/Hibernate/XML productivity while offering the same kind of integration and close to the same performance.

]]>