Is there room for both Rails and Grails in a company?
For the last week, I've been knee deep learning more about Rails and Grails. The reason is because I think developers (and companies) are going to have a hard time deciding which framework is best for them. The real question is: do they both do the same thing or are their different applications for each? Is "Grails vs. JRuby on Rails" a "Struts 2 vs. Spring MVC vs. Stripes" argument - where they're all so similar it probably doesn't really matter which one you choose?
Of course, the Stripes folks will object, but I really don't think it's that much better than Spring MVC 2.5 or Struts 2.1. Sorry guys. ;-)
If it is a Spring MVC vs. Struts 2 type of argument, then it seems to make sense for a company to standardize on one -- don't you agree? Does it make sense to allow both frameworks in a company if they're so similar?
Google has had much success in restricting its allowed programming languages to C++, Java, Python, and JavaScript. Shouldn't other companies do something similar? It seems like a good idea to restrict allowed web frameworks to a few as well. For companies with successful Java infrastructures, it seems logic to allow one Java-based web framework and Rails or Grails for getting things done as fast as possible.
Here's the sticking point: Ask any Rails developers and they'll say Rails wins hands down. Ask any Grails developers and they'll say Grails is the easy choice because it builds on top of Java's strong open source projects. Blah, blah, blah - where's the objective voice that's identified the "sweet spot" for each?
The Relevance guys, particularly Stuart Halloway, has a post about How to pick a platform. The logic in this post seems to imply that both frameworks do solve the same problem - just in different ways. Stu seems to recommend Rails for most applications, because Ruby is a better language. He says Grails might win if you have "an established team of Spring ninjas".
I know Stu and believe he does know his stuff (in both Java and Ruby). So is this the definitive guide on which framework to choose? If you have a staff full of Java developers, they should start learning/using Rails rather than doing the easier transition to Groovy, which they pretty much already know?
I don't know what the answer is, but that's what everyone seems to be saying. The problems is, the authorities on this matter (Rails vs. Grails) are often "head honchos" in companies that have a vested interest in seeing their respective framework/platform succeed. Since the Relevance team employs some Grails developers, it seems they're less biased. But who knows.
Is Rails really head and shoulders better than Grails? I don't think so, but I've only been programming with both for a week.
- Login or register to post comments
- 2252 reads
- Flag as offensive
- Email this Story
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Steven Devijver replied on Wed, 2008/01/30 - 2:03pm
From a technical perspective Grails is clearly the winner compared to Rails, with a big margin. It's easier to deploy, easier to cluster, easier to integrate with Java applications, ... .
For many people these arguments do not matter and for many other they do. Saying that any one of both Rails or Grails is better in general is according to me baseless. It all depends on what you need.
And like with previous battles of the frameworks many people will continue to choose frameworks for the wrong reasons.
Markus replied on Wed, 2008/01/30 - 3:31pm
I think it would be good if developers had at least a basic understanding of both frameworks. Then you can make a better decision which one to choose.
It also depends on what type of company you are. If you are only developing for yourself (if you are a company with a social network, for example), you probably want to focus most of your efforts on one framework, so your team can be full of specialists and you get the best out of the framework.
If, on the other hand, you are developing many applications for different clients, it might be great to have in depth knowledge about both frameworks (and maybe also about other stuff like JBoss Seam or Django), so you can deliver what the clients wants.
Markus
http://www.codekite.com
Alex Popescu replied on Wed, 2008/01/30 - 4:04pm
I would strongly everyone looking at Grails and Rails to also take a look at Django (the Python web framework). If you follow Steve's arguments than Django is also a winner when compared with Rails. The only thing that may confuse those looking at it is the version which is still under 1.0, but I wouldn't say that its quality is reflected by that number.
./alex
--
.w( the_mindstorm )p.
Robert Hicks replied on Wed, 2008/01/30 - 4:48pm
Roger Voss replied on Thu, 2008/01/31 - 12:42am
"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."
Matt Raible replied on Thu, 2008/01/31 - 5:32am
in response to: rv49649
Spending time with either Rails or Grails is a waste and a step backwards.It will be more rewarding to just move on up to Flex RIA + SOA style web app development.
I agree that SOUI/SOFEA-style architectures are more pleasurable to develop with going forward - but this doesn't help companies who have enjoyed success with traditional web applications - like Amazon.com, eBay.com, etc. They're not going to change to RIA when they've been incredibly successful with their current Web 1.0-style infrastructures.
Also, there's nothing preventing you from developing your RESTful backend with Rails or Grails, is there?
Graeme Rocher replied on Thu, 2008/01/31 - 6:34am
in response to: rv49649
Spending time with either Rails or Grails is a waste and a step backwards.This is complete nonsense to be honest. Whether you're doing RIA/SOA style applications or not you still have to deal with the server side component unless persistence is not a concern for you.
Flex RIA applications only solve the view layer, frameworks like Grails aim to solve many pieces of the puzzle from the build system down to the ORM layer and through the plugin system things like search, job scheduling and so on. Even RIA applications will have these requirements.
Why not get the best of both worlds and use them together: http://grails.org/Flex+Plugin
Rick Ross replied on Thu, 2008/01/31 - 7:45am
in response to: alexandrupopescu
Thanks, Alex. I'm glad to see Django find it's way into the discussion, too. It seems to be incredibly well thought out, and I am blown away by some of the sites I have seen powered by Django. DZone presently runs a few of our services withRails, and I'm betting we'll have some Groovy/Grails in the mix before long, but Django is also super interesting.
Rick
Rick Ross replied on Thu, 2008/01/31 - 7:50am
in response to: mraible
I suspect many people will be shocked by the lineup of mega-corps that Adobe has already partnered with to deliver major Flex/AIR applications. We've already seen a pretty slick Google Analytics client emerge during the AIR beta testing, and a lot more from similarly huge names (over 100, I think) are lined up. In fact, EBay has been maintaining a powerful AIR client app religiously since early beta - and users don't have to click refresh 1000 times during the last 5 minutes of an auction any more.
I guess my point is: don't be so sure big players won't adopt RIA strategies. Some of the evidence is starting to suggest otherwise.
Rick
foo doyle replied on Thu, 2008/01/31 - 8:49am
I'm a Grails fan but looked @ Rails first (before Grails). The truth IMO is that Rails is just more expensive if you are already in the Java Enterprise. Think of all the infrastructure you need to create for Rails and retrain your ops guys, deployment specalists, spec writers. I won't mention scale. But I know at least one company who is married to Rails and has a servers in every spare space possible to run the app. Grails just makes sense if you already have a JEE enviromnet less training and retooling. That said I think that SEAM and grails can live together much better. Rails is great if you start with Rails IMO.
Sidebar we have some NITRO development here for a proof of concept. I'll try to post the outcome later.
Graeme Rocher replied on Thu, 2008/01/31 - 11:27am
in response to: rick
I suspect many people will be shocked by the lineup of mega-corps that Adobe has already partnered with to deliver major Flex/AIR applications. We've already seen a pretty slick Google Analytics client emerge during the AIR beta testing, and a lot more from similarly huge names (over 100, I think) are lined up. In fact, EBay has been maintaining a powerful AIR client app religiously since early beta - and users don't have to click refresh 1000 times during the last 5 minutes of an auction any more.
I guess my point is: don't be so sure big players won't adopt RIA strategies. Some of the evidence is starting to suggest otherwise.
Rick
As per my previous comment there is little doubt that the RIA space will become bigger, but that just means they will have bigger and more complex issues to deal with on the server side such as persistence, job scheduling, batch, search etc. etc. all stuff Grails can help out with ;-)
Roger Voss replied on Thu, 2008/01/31 - 9:53pm
in response to: gr34134
Spending time with either Rails or Grails is a waste and a step backwards.
This is complete nonsense to be honest. Whether you're doing RIA/SOA style applications or not you still have to deal with the server side component unless persistence is not a concern for you.
Flex RIA applications only solve the view layer, frameworks like Grails aim to solve many pieces of the puzzle from the build system down to the ORM layer and through the plugin system things like search, job scheduling and so on. Even RIA applications will have these requirements.
Why not get the best of both worlds and use them together: http://grails.org/Flex+Plugin
With RIA, MVC is entirely on the client side. So the client just does "AJAX"-style service interactions with the server (or messaging if you use something like BlazeDS).
We use Tomcat/Spring/Acegi/BlazeDS (and other stuff). The services are very straightforward Spring POJO beans - handling either messages, method invocation, or even HTTP PUT. In our case we use iBATIS at the DAO layer.
There's just not even the tiniest flicker of server-side MVC web framework involved. The veteran developers that have spent years trodden down by web framework non-sense are really loving the RIA + SOA approach. These days there's zero interest in Rails/Grails/Wicket/Tapestry/JSF/etc malarchy any more.
Spring has coverage for batch processing, scheduling, can tie in with report generators via Spring, can combine Spring with Hibernate/JPA/iBATIS, and there's SpringJdbc template to deal with persistence, my favorite - JMS messaging (BlazeDS has an adapter for JMS), there is also OSGi, and JCache (several choices are supported via Spring). So don't need any other framework in there gumming up the place to deal with any of that.
--Roger
"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."
Graeme Rocher replied on Fri, 2008/02/01 - 5:58am
in response to: rv49649
Spending time with either Rails or Grails is a waste and a step backwards.
This is complete nonsense to be honest. Whether you're doing RIA/SOA style applications or not you still have to deal with the server side component unless persistence is not a concern for you.
Flex RIA applications only solve the view layer, frameworks like Grails aim to solve many pieces of the puzzle from the build system down to the ORM layer and through the plugin system things like search, job scheduling and so on. Even RIA applications will have these requirements.
Why not get the best of both worlds and use them together: http://grails.org/Flex+Plugin
With RIA, MVC is entirely on the client side. So the client just does "AJAX"-style service interactions with the server (or messaging if you use something like BlazeDS).
We use Tomcat/Spring/Acegi/BlazeDS (and other stuff). The services are very straightforward Spring POJO beans - handling either messages, method invocation, or even HTTP PUT. In our case we use iBATIS at the DAO layer.
There's just not even the tiniest flicker of server-side MVC web framework involved. The veteran developers that have spent years trodden down by web framework non-sense are really loving the RIA + SOA approach. These days there's zero interest in Rails/Grails/Wicket/Tapestry/JSF/etc malarchy any more.
Spring has coverage for batch processing, scheduling, can tie in with report generators via Spring, can combine Spring with Hibernate/JPA/iBATIS, and there's SpringJdbc template to deal with persistence, my favorite - JMS messaging (BlazeDS has an adapter for JMS), there is also OSGi, and JCache (several choices are supported via Spring). So don't need any other framework in there gumming up the place to deal with any of that.
--Roger
"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."
Hilarious how this post is a complete contradiction, in one sentence you're saying "we do RIA we don't need the server side anymore" and in the next you saying you use Spring for batch/scheduling and Hibernate/JDBC for persistence with JMS messaging.
Am I being blind or can anybody else see the contradiction in terms? Reality check, any client -> server application (yes that includes RIA) are going to require a server side component which deals with all these tasks you've just contradicted yourself in describing.
BlazeDS? Sure use it with Grails: http://grails.org/Flex+Plugin. And have Grails ease the pain of all of the other stuff that you need to get an RIA working. We even have guys using parts of Grails in Swing applications (http://jweldin.com/blog/?p=6). The reality is RIA only solves one part of the picture: the client.
If you're happy dealing with all of that in pure Spring, good for you, but there are many that see the benefit of doing it in Grails.
All this RIA is gunna cure world hunger is complete drivel. RIA "might" mean the death of MVC only frameworks which only provide the view layer (struts, webwork etc.), but frameworks like Seam, Grails, and JRuby on Rails which offer the full stack still have plenty to offer.
Kumar Pandey replied on Fri, 2008/02/01 - 11:42am
in response to: gr34134
Roger Voss replied on Fri, 2008/02/01 - 3:45pm
in response to: gr34134
What's inconsistent?
All along I've merely pointed out that server-side MVC web frameworks are unnecessary when doing architecture approach of RIA + SOA.
In our case we take the widely popular approach of rolling the SOA in this equation on a Tomcat/Spring/BlazeDS/ActiveMQ/Acegi/OSGi custom application server stack.
But there is zero web framework (MVC) involved on the server-side - just service call beans and messaging beans.
Refer to my JavaLobby posting:
Web frameworks peaking toward obsolescence
--Roger
"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."
Dimitris Menounos replied on Mon, 2008/02/04 - 4:25am
in response to: gr34134
Am I being blind or can anybody else see the contradiction in terms? Reality check, any client -> server application (yes that includes RIA) are going to require a server side component which deals with all these tasks you've just contradicted yourself in describing.
...All this RIA is gunna cure world hunger is complete drivel. RIA "might" mean the death of MVC only frameworks which only provide the view layer (struts, webwork etc.), but frameworks like Seam, Grails, and JRuby on Rails which offer the full stack still have plenty to offer.
You didn't understand what he said.
The thing is that with the RIA + SOA model there is no more need for server-side MVC frameworks (as you also point out). With that given, the usefulness of solutions like Seam/JSF or Grails is greatly limited because of the dissanalogous and unecessary complexity they add to the project in comparison to the small benefit.
Were I work, our latest projects have been build with AJAX on the client and Servlets+Spring+Hibernate on the server. The result is much cleaner code at both ends. What is also great is that the computing load between the client and the server is better balanced.
Graeme Rocher replied on Wed, 2008/02/06 - 12:52pm
in response to: agnus
You didn't understand what he said.
The thing is that with the RIA + SOA model there is no more need for server-side MVC frameworks (as you also point out). With that given, the usefulness of solutions like Seam/JSF or Grails is greatly limited because of the dissanalogous and unecessary complexity they add to the project in comparison to the small benefit.
Were I work, our latest projects have been build with AJAX on the client and Servlets+Spring+Hibernate on the server. The result is much cleaner code at both ends. What is also great is that the computing load between the client and the server is better balanced.
I know I completely understood what he said, its the two of you not understanding what I am saying. Frameworks like Grails, Rails and Seam are not just simplifying the client, but the entire end to end.
In other words, you can completely remove the MVC layer from the picture (controllers/views/taglibs in the case of Grails) but still get massive benefits because something like GORM greatly simplifies the use of Hibernate, Grails itself simplifies the usage of Spring, and through its plugins things like Quartz, messaging, search are simpler
The misunderstanding here is from you guys who think something like Grails is just an MVC framework, its not, its a software stack simplifying all the layers. As you've pointed out you're using spring, servlets and hibernate on the server, so why not make that simpler and use Grails.
Roger Voss replied on Wed, 2008/02/06 - 8:14pm
in response to: gr34134
Well, it's true we're using Spring for it's DI and many templates and wrapper abstractions over various enterprise services - all the while sidestepping Spring MVC (other than just Controllers - no view generation, etc) and of course Spring Web flow (all the user UI state context is down on the RIA client-side).
So now you're saying that Grails could be inserted as yet another abstraction layer over some of the same things Spring is currently providing?
Things are already so simple in terms of what a developer has to do - to come in and add a middle-tier module to provide some new service. Sure we had to go through a bit of effort to wire up our own custom app server framework, but from here on its basically gravy.
Would using Groovy be the sales point for going Grails or is it the proposition that Grails can make life even simpler than the Spring Framework can (keeping in mind we have zero interest in MVC state management on the server-side), or is it the Grails persistence model?
From what am reading in your last response, is that Grails would do same things that we're already doing but just be easier and simpler. If it's only marginally better then that wouldn't be sufficient justification to throw Grails into the stack. It would need to be a substantial win over just Spring.
"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."
Graeme Rocher replied on Wed, 2008/02/06 - 10:57pm
in response to: rv49649
Yes that is exactly what I'm saying, Grails can be seen as the next level of abstraction over Spring. However, another thing to remember is Grails is Spring. It is built on top of it.
As for whether it would give you benefits I would say that you should try it yourself, if you're happy just using Spring that is great too. However, many have found benefit in using Grails as a wrapper for Sping and Hibernate. GORM pretty much completely eliminates the need for writing a DAO layer, we have things like the Searchable plugin which makes lucerne search (with compass) trivial. A quartz plugin that simplifies job scheduling and so on.
Plus of course, as you say, you get the Groovy languages which makes programming in general simpler for many cases and can be nicely intermixed with Java code.
Roger Voss replied on Thu, 2008/02/07 - 12:15am
in response to: gr34134
So at a conference session on Grails I attended, the whole emphasis was on illustrating how Grails could be used to quickly whip up a web application - very much like the Dave Thomas sessions for Ruby on Rails I attended when RoR first started spilling into Java conferences.
There was not much in that I saw - other that it was using Hibernate for persistence - that indicated Grails was abstracting other enterprise services. In fact, I guess I can't recall that much being said about the use of Spring at the time either.
So sounds like perhaps Grails has expanded its horizons since those earlier days.
Up to now Spring is about the only server-side framework I've seen that has had an immense breadth to offer for enterprise programming besides merely orchestrating MVC for conventional web applications.