The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Geoffrey Wiseman on Jul 11, 2007
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.
Monitor your Production Java App - includes JMX! Low Overhead - Free download
18 agile and lean practices for effective software development governance
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
If it's not a direct port of Rails and only borrows some concepts from Rails maybe they shouldn't have started out with the name Groovy on Rails and when they did decide to change it maybe they should have picked something totally different. The misconceptions problem would probably be a non-issue then. (Disclaimer: I'm a huge Grails fan)
Similar considerations for "Grails is not mature enough for me": the current stable version is labeled 0.5.6. Most people will probably wait for the 1.0 release before considering it "mature enough".
I certainly agree with both of your points, unfortunately changing the name now would be tough going.
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.
Few things to point out:
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
a) Not sure where you get this 6 req/sec figure from, maybe you were benchmarking against development mode. As Marc's blog said use "grails war" create a war ready for production. There are benchmarks on the grails site showing grails processing over 100 req/sec
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
I'm interested to see more REST support in Grails, I gather it's entirely possible to do, just not 'incredibly easy' to do (see RoR 1.2's REST support e.g. resource_scaffold). Am I misconceiving how easy it is to do now? I wasn't able to track down a quick five-minute "how to do REST in Grails" post anywhere, so if it's really easy to do, perhaps someone should write up a quick blog entry on the subject?
Fact is with a different name, Grails wouldn't have raised that much interest as it did.
I feel like I have to correct my self. Really in production it is about 40r/s
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 ....
grails generate-all completes in 42s on my MacBook 1.83ghz, but yes we need to improve on this.
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 ;-)
And btw if you are basing the speed of development on the speed of generate-all and scaffolding then you must be developing pretty boring apps or not using the frameworks as intended.
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.
The seamless integration with Java is such a huge win in my book. If I was going to create my own website I might not use Grails since hosting a Java webapp is not the easiest...
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.
What is the percent in Spring with JSP ? 80% seems quite high.
80% is high, that is why we know it us our bottleneck ;-)
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
Having already deployed an Ajax, CRUD, Grails app on at work, I can tell you that:
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.
Another big plus for me is that I can plug in code that works with Spring, so the Grails platform can be expanded fairly easily to use loads of other libraries.
My favorite part.. is they release a book.. that was for versino 0.3 of grails.
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 :)
I'm the author and Grails all the way up to version 0.5.6 is backwards compatible. We have only made one change in 0.5.6 that is not and its in the releasen notes.
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.
We are a spanish software development company (ImaginaWorks Software Factory: www.imaginaworks.com), our core business is to develop custom software for other companies, mostly web-based. We adopted Grails as our main development platform in April, and all I can say is that our productivity has multiplied by 2 or 3. Once we got used to Grails way of manage artifacts and applications, we are able to create a prototype in 10 minutes, and update existing sites much more quickly.
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...
Even if Servlet + JSP are faster, this doesn't mean you will end up doing faster applications in standard J2EE. If you are not experienced you will end up loosing this speed advantage and not to talk about productivity.
Graeme, can you detail what is the slowing down GSP views ? Is it SiteMesh, taglibs or something related to Groovy ?
It is a number of different things. The parser is a bit naive so when producing multi-line static content it would do something like:
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
Me Me, would you please use your real name on your InfoQ posts?
Where can I change it ?
I found it
I´m still at my first steps at Grails development, but I can say that it´s really incredible.
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.
Graeme, Netbeans 6.0 has very nice dev env for ruby/rails, do you see something like this in the near future for Groovy/Grails (perhaps via Coyote project).
I'd have to second Nicolas' commments. Grails development is FAST. We wrote our website tvvoting.com on Grails and it works great. We have had some performance bottle necks but have been able to sort them out by refactoring views and using more AJAX. Although there was not great IDE support, we still got it up very very quickly.
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
From everything I have heard, Grails is an excellent framework for Java web applications; however, I have to disagree with the following comment: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.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
27 comments
Watch Thread Reply