Is developer productivity improved on Ruby on Rails or Grails?

Question

Given that Ruby on Rails (RoR) and Grails can run on the Java Virtual Machine (JVM), which language and structure allows more competent and experienced developers to work more productively and at about what percentage? (i.e. provide greater business functionality with the same volume)

I know that Grails is easier for a Java developer to switch to. And I understand that the entire Java library is available to the Grails developer. My question is about developer productivity in an environment where one runs on the Linux JVM using standard application servers (WAS, Weblogic, JBOSS, TOMCAT, etc.). Note. JRuby will be used to enable RoR in the JVM.

I would request answers from those who have made significant web application development using both ROR and Grails.

Answer 1

If all you are looking for is a 75% answer : grails

I made significant development on both platforms, although my main experience with rails ended about a year and a half ago (before the release of rails 2.x).

I actively participated in the development of the Grail with a Grail of 0.5.

The answer really depends on the developers and infrastructure that will be available to work on the project. If you want to deploy a standard container of java applications (e.g. Tomcat), I think Grails is the best choice. If you want to do something with mongrel / rack / pound / etc. Choose rails.

If there are specific gems / banks that match your business problem, this will obviously affect your decision.

Choosing Grails for me is not so much because I think it’s better to solve all kinds of problems, but more because I like the Grails developer community and I like groovy a little more .

I also found that grails are easier to sell in places where I worked on rubies / rails. There are many more java stores here, and for them this is not just a leap to make this transition.

This is a personal preference, and I could easily see how someone else goes the other way.

Rails has a lot of things to do, and I think the test-based development history is much better (although I'm working on trying to fix this ).