Summary
I asked Guillaume Laforge this question at the JavaGruppen conference in Denmark while he was giving a compelling presentation on Grails.
Advertisement
Guillame gave an amazing demo where he built an enterprise app interactively. He described a feature as he wrote a line or two of meaningful code, and the feature magically appeared in the application. Watching this, I could imagine building an application live, with the stakeholders in the room making requests and giving feedback as the application is created. The only thing missing was the polish, which can be added later.
Although its name certainly derives from Ruby on Rails, Grails is primarily inspired by Rails' productivity rather than its design. In particular, Grails has gone out of its way to avoid some of the well-known scaling problems with Rails. Indeed, scaling was one of my prime considerations when I asked Guillame the above question.
His answer was that there is nothing that Grails can't do that (for example) EJBs can do. As far as scalability goes, Grails is built atop Hibernate and Spring and so contains all the scaling power of those frameworks.
The most impressive thing is the way that Grails pushes the dynamic nature of Groovy as hard as it can, so that every line of code is concise and meaningful. Contrast this to EJBs: an ivory-tower thought experiment that had little to do with how people actually develop software, and as a result was terribly confusing and required all kinds of needless ceremony. Many parts (entity beans, for example) simply didn't work. The losses that resulted from having EJBs foisted upon us has been estimated in the billions.
Does this make me a Groovy/Grails guy now? No, but only because Python is still my primary language of interest, so I would probably try TurboGears or Django first. However, I can easily imagine constraints where Grails is the right solution.
I come for the Java / JEE world : I work with Rails for 3 years, in parallel of Java. I began with Grails while learning Rails for comparison. I have more experience with Rails comparing to Grails.
My conclusion after several projects with Rails: Rails is for me less enterprise ready than Grails: the enterprise Intranets are nowadays overloaded with J2EE stack, well integrated with third party enterprise products. Grails has already the advantage for this: Grails has the advantage to be well integrated with Java, built on products like Hibernate+Spring, and Grails apps are natively deployable into J2EE app servers. I do not speak from EJBs it was a nightmare for me. My experience with deployment and performances with Rails : I tried different mixes : Apache/FastCGI, Lighttpd/FastCGI, NGinx/Mongrel, Apache2/Mongrel. I wasn't satisfied about performances, even for simple apps, comparing to J2EE apps running on App Servers like Oracle AS, JBoss, Glassfish. Rails 2.2 + new comers like Thin or Phusion Passenger (mod_rails for Apache) certainly could enhance performances. Many new things are coming with Rails 3 (principally some merge with the Merb framework) Even Ruby 1.9 and its new YARV VM + future of Threading in the Ruby VM should be considered for performance enhancements. Finally i would say, the chance Rails has to enter the enterprise is to make run Rails apps on JRuby and deploy into J2EE App Servers: finally Rails apps will really compete against Grails apps, and we'll can compare...
> The losses that resulted from having EJBs foisted upon > us has been estimated in the billions > > I'm no fan of EJB but do you have a source for this claim? > Nobody was forced to use EJB.
I was. Not physically but I generally try to avoid insubordination.
But I think Bruce means that EJB were sold as a panacea and a lot of people bought into it.
Ultimately, though, the fault is with those who failed to give the proper amount of skepticism to an unproven idea.
I've never done EJBs--thankfully managed to avoid that--but I did get turned down by a lot of recruiters because of it. They seemed to think that because I hadn't done EJBs I hadn't done enterprise Java, when nothing could be further from the truth.
I've done a lot of Jython scripts to drive enterprise-ish Java--how does Groovy compare?
> I've never done EJBs--thankfully managed to avoid > that--but I did get turned down by a lot of recruiters > because of it. They seemed to think that because I hadn't > done EJBs I hadn't done enterprise Java, when nothing > could be further from the truth.
It's funny too that I've known people who have plenty of experience working with EJBs but have almost no understanding of the fundamentals of Java or programming in general.
seriously ? You never had to work for an "architect" or other manager who said, "we're using EJB for this, its enterprise ready" ? Lucky you. Try EJB 1.0 even, before anyone had even tried to use it, hibernate didn't even exist as an alternative. Boy that was fun.
> I've never done EJBs--thankfully managed to avoid > that--but I did get turned down by a lot of recruiters > because of it. They seemed to think that because I hadn't > done EJBs I hadn't done enterprise Java, when nothing > could be further from the truth. > I'm a Contractor and I can relate. Persistence Frameworks, home grown stuff, Spring, but unfortunately that doesn't cut it.
When you actually list on your skills and accomplishments that you have written enterprise Java apps. They fire away questions about Entity Beans.
When you tell them that all your previous employers have opted for alternative solutions, these knit-witted code monkies look at you with this blank stare. I'm usually thinking to myself - and you call yourself Architect.
I'm not expert, I like the save/reload style development. But feel gails still in a very pre-mature stage:
1)there's no built-in support for master/detail forms, the demo is nice, but I can't see how easy if I need to display master/detail form in the same page.
2)documentation is still at very initial stage(i.e. most of them just tell you how to establish the first web application), developer need to figure out lots of details if want to do any thing more complicated. 3)huge number of plug-ins: good and bad. On one hand, you have plenty of choise, on the other hand, you need to learn/explore the plug-ins case by case. Often you will find plug-ins are not work as expected, or they won't communicate to grails as expected. 4)no struts2 plug-in (I did find a strut1 plug-in). given struts2 is still the de facto platform, why can't one use strut2 + grails in parallel? 5)compare to seams, grails is now founded by a small company, not sure how far it can go
We did quite a bit of "change while talking to the requester" using web2py -- it's running alongside django for PyCon2009, handling registration, financial aid, and more.
Previous Topic
