Grails Misconceptions
- Share
-
- |
Read later
My Reading List
Marc Palmer, a Grails committer, posted about some of the common misconceptions that developers have about Grails, such as "Grails is not mature enough for me":
The increasing number of live commercial sites is the best answer to that. Its also built on Hibernate, Spring and SiteMesh which are well-established technologies, not to mention the Java JDK which is as old as the hills. Groovy is over three years old.
And, in response to "Grails uses an interpreted language (Groovy)":
Groovy compiles to Java VM bytecode at runtime. It is never, ever, ever interpreted. Period. Never. Did I say never ever? Really.
Finally, talking about whether or not Grails is just a clone of Rails:
Ruby On Rails introduced and unified some great ideas. Grails applies some of them to the Groovy/Java world but adds many features and concepts that don't exist in Ruby, all in a way that makes sense to Groovy/Java programmers.
Graeme Rocher followed up with his own list of misconceptions and questions, such as "Who needs Grails when we have JRuby on Rails?":
This is a classic and is the foundations for one of the biggest misconceptions about what Grails is. JRuby on Rails is an excellent way to run Rails apps on a Java EE container like GlassFish. End of story. Grails has very different goals. It is not a port of Rails to the Groovy language. It is the act of bringing together solid industrial strength components like Spring, Hibernate, Quartz, Compass, Sitemesh etc. and making them DRY by embracing convention-over-configuration.
We're not re-inventing the wheel and because the vast majority of the core of Grails is Java it is more robust and performant. Grails is actually a Spring MVC application at its core and is deployable onto all major containers, not just Glassfish, including the big commercial ones such as WebLogic, WebSphere and Oracle AS.
And, "Why is Grails more suitable than Rails for the enterprise?"
A number of reasons. Two of the biggest ones are Spring & Hibernate. As it stands to day a enormous number of organisations are using Spring & Hibernate. They have existing Spring context, existing Hibernate domain models, and so on.
I was in this same situation before I started working in Grails. Grails is designed to integrate with these frameworks as seamlessly as possible. So for example you can drop a Hibernate domain model written in Java and mapping files into a Grails app and start using dynamic finders and GORM straight away.
In addition Grails controllers use standard Servlet API objects like request, response, session etc. and can sit alongside other servlets. It is after all just a Spring MVC application under the covers. Rails on the other hand is designed almost in a way EJB2 was designed (shock, horror bear with me while I qualify this). In other words you extend framework objects like ActiveController, ActiveRecord etc. which bind you to the framework.
There is also no such thing as a domain model in Rails. Rails models are database tables. This is all well and good, but in enterprises the same domain model is often re-used in multiple applications both desktop and web. This is effectively accomplished in Java by packaging the classes with the mapping files in a JAR.
Do you have other questions about Grails, or have you seen other misconceptions about its use? Share them with us here, on InfoQ's Java community.
Maybe they should have chosen a different name
by
Brian Dittmer
Re: Maybe they should have chosen a different name
by
Mirko Nasato
Re: Maybe they should have chosen a different name
by
Graeme Rocher
As for 1.0, we're working towards a release later this year, but your point certainly stands. Once the 1.0 release is out I hope more people will consider Grails as an options.
Grails vs Rails
by
Sergei Rogovskiy
a) why is it so slow if it is complied java bytecode. (6 req/sec on high-end g5)
b) one of the main ideas on Rails is no XML. This was totally ignored by Grails as far as I can see which makes it another java thing where java and xml are randomly mixed up.
c) generate model takes forever - development tools are slow
To conclude: a) - c) makes development slow which is directly opposite from what you can see in Rails.
P.S. I am a java guy btw
Re: Grails vs Rails
by
Graeme Rocher
b) What XML? You can write an entire grails application without touching a line of XML. Sure we allow access to the Spring XML if you want it, but its not a required activity
c) Yes we're working on improving this, but its a once off activity. I'm not generating scaffolding code all the time personally.
Cheers
Graeme
Re: Grails vs Rails
by
Geoffrey Wiseman
Re: Maybe they should have chosen a different name
by
Sebastien Auvray
Re: Grails vs Rails
by
Sergei Rogovskiy
ab -n 1200 -c 30 "http://localhost:8080/test-0.1/book/list"
Requests per second: 43.49 [#/sec] (mean)
Which isn't great I'd say, still not six.
But...
grails generate-all Test 41.66s user 152.06s system 99% cpu 3:15.63 total
I really hope that something is wrong with my machine... cause it doesn't have to take over 3 minutes to generate 5k of code.
Anyways, I think the big thing for rails is development cost cut which is not entirely possible with grails at least right now.
I think it doesn't really make sense to make comparison right now. Neat idea, but need to work on implementation ....
Re: Grails vs Rails
by
Graeme Rocher
As for the performance, we're aiming to improve this, but as the benchmarks show, we're still faster than Rails:
grails.org/Grails+vs+Rails+Benchmark
Currently our bottleneck is the view tech, GSP which takes about 80% of the request processing time.
So although yes we need to improve, and work to optimise (a part of the dev cycle we haven't reached yet) we're not the only implementation that needs work ;-)
Re: Grails vs Rails
by
Graeme Rocher
Grails and Rails are for far more than just CRUD, and most experienced Grails/Rails users tell you, you start off using scaffolding as a learning tool, but quickly abandon it and just use the framework itself.
Makes me love Java
by
Thom Nichols
But for enterprise development on the Java platform, it's hard to beat :) Stability is great too. Even the snapshot builds are fairly stable and backwards-compatible.
Re: Grails vs Rails
by
Marius Vasilache
Re: Grails vs Rails
by
Graeme Rocher
Obviously it depends in the GSP view (simple or complex) but we need to work on the parser and improve it then Grails will be blazing fast.
Cheers
Graeme
Re: Grails vs Rails
by
Nicolas Doye
- If I'd used Perl, PHP or a Java framework, it wouldn't be finished, and would probably not contain the Ajax part.
- If I'd used RoR, I'd still be learning Ruby :-) Groovy is so Java-like (plus I get to call Java stuff I already know) and GSP so JSP-like, it's a piece of cake to learn.
- It's fast enough - sure it's slower than Servlet + JSP - but in the real world of sites that aren't receiving 500,000 page-impressions per day - who cares? Job done.
I'd say that (J)RoR and Grails both have a great future. They both meet a need and have sweet spots (like Perl and PHP both have done and still do).
nic
PS. I didn't write any XML for my application. Schweet.
Re: Makes me love Java
by
Jez Nicholson
Definitive Guide to Grails
by
Roger Studner
Note.. you coudln't use the book with 0.3
Or 0.3.1
Or 0.4
Especially not with 0.5
I've posted errata on the apress website.... no response.
I've attempted emailing authors... no response.
They should just take the book off amazon.com etc.. You can't get to page 65 in it, with any version of grails :)
Re: Definitive Guide to Grails
by
Graeme Rocher
I've had no e-mail from you personally, but we have a very enthusiastic mailing list, where you can post your problem and we'll help out.
Productivityx3
by
Nacho Brito
And we've touched no xml config file since then, all of our configs are groovy files :-)
It's true that the framework is a bit unstable at this moment, some migrations (specially 0.4.2 -> 0.5) are a bit scary, but the development team are allways there to give you a hand, and finally everything goes smooth...
Re: Grails vs Rails
by
Marius Vasilache
Graeme, can you detail what is the slowing down GSP views ? Is it SiteMesh, taglibs or something related to Groovy ?
Re: Grails vs Rails
by
Graeme Rocher
out.println('..')
out.println('..')
instead of a single call (using the platform dependent line separator of course)
out.println('..\n..')
And we could make better use of string interning and constants for static portions of content. Plus reduction of thread local lookups. So there are three areas of optimisation:
a) make the parser more intelligent to merge static portions into a single call
b) using string interning and constants for static portions of content
c) reduce thread local lookups and tag invocation overhead
Re: Grails vs Rails
by
Floyd Marinescu
Grails is the best
by
David Nelson
The only issues that I can say it´s the lack of IDE support and performance.I´m already using the new IntelliJ plug in, it´s not done yet, but seems to be very cool. And the performance is not that bad.
Comparing to Rails, GSP/JSP syntax is a lot better than RHTML, I used to develop in PHP and ASP and I really rate those <%= %> in my templates. I prefer Groovy than Ruby to, much more readable, Java-like, better syntax, and also have a lot of cool features like native EL.
Thank you guys...you are doing an excellent job.
IDE support
by
serge boulay
Re: Grails vs Rails
by
Jeff Bonnes
We also started a traditional Spring / Hibernate application about the same time that we are still completing with 3x the people on it.
Having worked on Grails and a traditional app at the same time, Grails wins hands down.
Jeff
Rails DOES have a domain model
by
Bill Siggelkow
There is also no such thing as a domain model in Rails. Rails models are database tables. This is all well and good, but in enterprises the same domain model is often re-used in multiple applications both desktop and web. This is effectively accomplished in Java by packaging the classes with the mapping files in a JAR.
Rails applications do have a domain model in a similar way that Hibernate-based applications have a domain model. In my Rails application models, I use a mix of ActiveRecord objects and plain Ruby classes and modules. Rails supports both compositions and associations within an ActiveRecord model. For a simple example, I can have a Name class, which does not extend from ActiveRecord, that encapsulates the parts of a person's name and provides methods for formatting and parsing. I can reuse that Name class wherever it is needed.
As far as model reuse outside of the web application ... in practice, I find that this doesn't happen too often ... usually due to differences in the contextual use of the domain model. That being said, given Ruby's support for metaprogramming, I imagine that creating an ActiveRecord model that delegates to a non-ActiveRecord class object should be possible.
All in all, I have found it easy and natural to create a rich domain model in RoR applications. Rails applications lend themselves well to a thin controller/fat domain model approach.
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Concurrency in Clojure
Stuart Halloway May 17, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think