ALTERthought Blogs

[…] Catchy title. But the guys from ALTERthough have some - much needed - numbers. Their numbers show Grails to be more productive than Rails, which is in turn more productive than Spring and pure JEE. As I’ve argued for years, there is no science in computer science. We need to put facts back into computer science. Hard numbers instead of faery tales. Hacknot thinks so too. Thanks for the real numbers. Two thoughts: […]

This is a puzzle piece in the quest for hard data. As I and others - like Hacknot - have asked for years is hard data on development times, not faery tales. So this is a nice effort for such data. Thanks for providing them.

Two annotations though:

a.) JEE is a very broad term. It might include Seam. When comparing Grails (what we use) to Seam we saw a lot of similarities between those frameworks. It might be nice to take Seam into account in the future - at least do an estimation how much faster JEE would be with Seams.

b.) I guess this is only tracking development effort. Robert Glass shows that 40 to 80 % of life cycle effort goes into maintenance. Numbers for how good Rails, Grails and JEE far there would be nice. I suspect, but have no numbers, that JEE or Grails in static typing mode should outperform Rails.

Thanks for the numbers, they are very much appreciated.

Peace
-stephan

This is based on 1 project at 40% complete with teams and processes organized around Java? Shocking, truly.

I eagerly await the JRuby on Rails numbers.

Just a minor clarification — 40% complete = fully completed user stories. There are a number of user stories in various stages of completion, but for our purposes our team has not completed “earned” them because the entire functionality has not been delivered.

A couple of thoughts.

First My background is in Smalltalk, Python, Ruby, Rails. I am very buy into the dynamic language process.

One question what were your estimates on for the Grails based project and how do they compare to the estimates?

Two this is not Rails target application I am surprised that it was projected to work as well as grails for this app. 5.8% is equal at this level of accuracy.

good effort though I hope you update the report in the future.

Amazing…stunning…a bunch of Java developers think they are more productive on Java out of the box than Rails. I love the comparison against a Rails “estimate”. Sounds like marketing mumbo-jumbo to me, rather than actual numbers.

Get a couple of Ruby developers–real Ruby developers, not Java developers who’ve read the PP Agile Rails book–to build a comparible app on Rails. I bet your Java team will get dusted.

I’ve done a bunch Groovy programming. Sucks compared to Ruby.

Erik -
we opined that the Grails estimate would have taken “about as long” as Rails; however, this was our first attempt to benchmark grails productivity, so we did not have a Grails ‘index.’

Pico -
lol .. very “pithy” … Rails productivity estimate - born from real world experience .. with solid died-in-the-wool developers). Just facts .. and Planix (the tool we use/d to estimate) is written in Rails by us … that should tell you what we think of Ruby/Rails .. just trying to bring some “data” to the “we will dust your arse with x framework” conversation …

Ok….you’ve compared your Groovy actuals to Rails “estimates”? Seriously…how can you even believe what you’ve written based on this? Tripe.

that article made me want to try Grails. And maybe Seam. Although 3 “estimates” versus an “actual” is absolutely biased, to say the least…
I’m perfectly happy with Rails’ productivity, but as the customers use to prefer Java for several reasons, it would be good to have something as productive as Rails on the JEE world.

ps: Pico, shut up… You are the kind of person that makes everybody think Rubists are all stupid trolls…

[…] The potential productivity gains from learning groovy are being discovered and compared to other approaches in this interesting blog. […]

this comparison is superfluous !
how many weeks have you estimated for grails initially ?

“Get a couple of Ruby developers–real Ruby developers, not Java developers who’ve read the PP Agile Rails book–to build a comparible app on Rails. I bet your Java team will get dusted. I’ve done a bunch Groovy programming. Sucks compared to Ruby.”

That’s why I’m happy using Grails and Java. There are very few people like this guy.

Obviously the post is from a company which is a Rails shop. And as Graeme pointed out on his blog, the higher productivity in Grails doesn’t come from the language but the Java ecosphere.

But I’d really like to see a deployed JRuby on Rails application. With the Java open source ecosphere It should be more productive and faster than the current Rails applications. Perhaps this setup will replace a lot of current CRuby on Rails setups. The future is amazing.

Peace
-stephan

–
Stephan Schmidt :: stephan@reposita.org
Reposita Open Source - Monitor your software development
http://www.reposita.org
Blog at http://stephan.reposita.org - No signal. No noise.

I am one of the fellows that is involved with this initiative– in fact it was really my decision to go with Grails over Rails for a host of reasons (to be explained in greater detail in a future post) here.. but some of them included:

- Client has standardized on Java/J2EE. Since Groovy/Grails really == Java in the end, it was not as much of a hard sell.
- Developer base consists of experienced J2EE programmers. No real RoR. GoG was perceived as less of a learning curve. We are on a fixed price engagement so that is important.
- Application requirements required integrating to a mess of legacy systems. Notably:
* Multiple data sources (Informix, AS/400 (DB2), MySql)
* LDAP
* Various WebServices
* Java based API’s
* Message queues (WebLogic and MQSeries)
- The legacy DB’s in question generally have no distinct Object Id column.. the primary keys are composites of other columns. This seemed awkward in Rails (indeed its awkward in Grails, but we can do it via Hibernate)

I am certain that all of the above is very doable in RoR, as I do not profess to be an expert on it (or a Grails expert for that matter, yet) but I am a J2EE/Spring/Hibernate one. Given the Spring/Hibernate infrastucture of Grails I _knew_ we could accomplish our goals in short order using GoG (i.e.,when forced we can always punt and go back to Java).

Personally, I was less interested in how elegant/klunky the Groovy language itself was when compared to Ruby. What I wanted was the the infrastructure, frameworks and conventions that a Grails/Rails provided… and to that end we have gotten everything we were looking for.

As far as productivity: Its our first Grails app, and we had to compare it to something for estimation & planning purposes.

So the above is a little bit of context as to our architectural decisions… most notably that we never said ‘Rails sucks… Grails rocks. Lets use Grails!’

@don:

No, but the author of the article did say things like “as a business person, I will have a clear statement in the Rails/Grails debate: ‘I want all Grails, and I want it all the time.’” and “Down goes Frazier (Ruby on Rails), down goes Frazier …”. Your comment actually is a much better justification for selecting Grails vs. Rails in that you clearly indicate that it is the tool for the particular client’s job and it fits in with your expertise. The OP is just cluttered with too much flamebait.

@anthony - thanks for the comment …

honestly, imo, a little hyperbole to engender debate is sometimes a good thing; the answer to the Grails v Rails question is, undoubtedly, “it depends..” Its just that, for my money, if I’m paying for the gig (enterpreneur, CIO, CEO, product manager hat);

At this point in time, if the numbers continue to pan out, and the technologists continue to say things like “I wish we would have had this when we wrote “x” and could have gotten to market faster and still had the scale/extensibility needs figured out … ” Well, then I (with aforementioned hat) have to begin to ask for the right combo of productivity, maintainability, and all the other ‘ilities’ that you tend to inherit due to the vibrance and maturity of the java ecosystem.

We’ve see a fair number of clients start out in a scripting language, become victims of their own success, and need to spend $N million re-engineering to something that is not only more scalable, but provides additional analytical/advanced features … if one can acheive productivity with a particular platform and set themselves up for virtually limtless options in terms of feature development, operational scale, etc … why not?

To be perfectly honest; as a rubyist who has recently delved into Grails, I’m starting to agree. Beyond any potential flaws in this quantitative analyis (I’d like to see the raw data), my dear old startup needs some whiz-bang optimization mathematics as part of the normal application flow that I cannot accomplish in an efficient manner with Rails->servlet->pojo .. GoG and the java ecosystem *seem* to allow you to have your cake and eat it too ..

Interested but perhaps you should have titled it:

“Java Expert with little RoR experience finds Grails to be more productive than RoR and prefers it for ALL future projects”

Yeah - I guess no one would read that because it is TOTALLY EXPECTED.

Reverse that and I am pretty sure a RoR expert would be totally exasperated just trying to get past the learning curve and configuration issues and probably not finish the project. Maybe the reason that you used estimated RoR productivity.

What is it with you guys always trashing RoR - why don’t you surprise us and pick on Python/whatever, Seaside, PHP/whatever, ASP.net or anything other than RoR. Is it because RoR now the standard by which everything else is judged?

What I’d like to see is a web application development contest where a project is specified and teams of say three are given up to x number of hours to complete the project. Perhaps an entry fee for 10 teams to cover a a prize of 100K would help to put the money where the mouth is and put this to rest. I certainly wouldn’t want to compete against the likes of Avi Bryant however.

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.

@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!

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.

@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.

@ “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/

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.

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.

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.

[…] 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. […]

[…] À 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. […]