I would like to have jumped right onto the Rails bandwagon if it hadn't been for the fact that ActiveRecord offers only a fraction of what Hibernate does.
- Where is the proper transaction & conversation support?
- Why is it that it hits the db orders of magnitude harder that Hibernate does and is infinitely slower?
- Where is the criteria support? What about distributed caching?
And I would probably have said a long goodbye to Java, if it wasn't for the fantastic innovation that is happening in projects like Spring and Hibernate and the libraries that integrate with them (Quartz, Sitemesh, Compass, Acegi, Webflow et al) which Grails is built on. Want an RMI, burlap, http, soap or DWR service? Just expose one. Need advanced declarative security at the web and business layer level? Plug it right in. Job scheduling? Job done. Search? Sure no problem.
Spring and all the projects that integrate with it, make the Java ecosystem a very happy place indeed. So no, Grails might not have RJS (yet), migrations (yet) or xyz feature from Rails, but it has plenty, thanks to the Java eco-system, to make up for it and then some.
19 comments:
I find the whole Ruby/JRuby/Rails/Groov/Grails debate very interesting. So long I've been at home mainly in Javaland, so I'm pretty aware of the adavantages Grails has to offer in terms of Java-integration. My two major reasons why I probably will nevertheless try out Rails in future (now that you can deploy Rails application on the JVM):
- it seems to me that writing GSP code is much like JSP. And I hate to write these "c:choose c:when when c:otherwise.." tag orgies. It's just so ugly to write (and that is also the feedback of my project team's members) and I'm sick and tired of this.
- Rails/Ruby simply has just such a big momentum and I like to have a thorough understanding of the Rails platform to have an own attitude
By god man and you prefer Rails' scriplet based RHTML? That is strange..
scriplet <% %> orgies are even more lame, at least tags are well formed
If you enjoy tag-based views, hobo has DRYML, which provides the same (arguably, far more flexible) abilities.
Don't know if I prefer rhtml. I'd like to try it out and see, as I pointed out above. Maybe you're right. It's just the thing that a simple if-then-else is so very verbose having to write all those tags. Maybe I'll be sick and tired of rhtml even faster.
By the way I wish you all the best for Grails
Thanks Christian, and good luck with Rails or whatever framework you go with the end :-)
Cheers
Graeme
Indeed antonio, Hobo floors anything I've seen for cleaning up Rails at the moment. And it appears that some great things are going to be happening soon for it developmentally.
Hey Graeme I wrote a response to this but it was a bit too long for a comment.
Rails has the "less is more" approach wich I like very much after years of work with huge frameworks (je22 and .net). The real power of rails comes from the language, ruby. Java and C# seem clumsy to me now.
@antonio & george
The ideas from Hobo come from Grails. Tom Locke the creator saw Grails' taglibs before he started working on it as I showed him :-)
He won't admit he got the idea from Grails, I guess due to the not-invented here syndrom running through the Rails community (I'm happy to admin we took many ideas from Rails). Sorry Tom, but this is fact!
@gernot
Sure, if you feel RJS is more important than transactions than go for it ;-)
I don't imagine many big enterprises will.
@masukomi (kate)
I posted response on your blog
You don't have to use RHTML with rails, there's always haml: http://haml.hamptoncatlin.com/
HAML looks lovely, unfortunately I doubt any designer tools like Dreamweaver will grok this:
#content
.left.column
%h2 Welcome to our site!
%p= print_information
.right.column= render :partial => "sidebar"
We chose to use tags for a reason :-)
Or better yet (re: rhtml,haml,etc), Markaby :)
or whatever else suits your fancy, liquid, etc.
Personally I think HAML looks like garbage. I realise it's nice and terse but it's very ugly looking and as Graeme already mentioned, tools like Dreamweaver won't like it one bit.
That said, I think things like JSP, HAML and RHTM are antiquated ways of doing web development and MUCH prefer using Wicket for web development. It's the only thing that doesn't make me cringe when I look at it. Grails has a plugable view technology so I'm interested to see how far Graeme can take Wicket on Grails. :)
AFA Dreamweaver and HAML: It shouldn't be much harder than parsing CSS. I don't see why that would be a problem.
AFA Transactions: Rails has had transactions since before Rails 1.0. I'm not sure where you got the idea that they didn't.
I've never heard of 'conversations' or 'criteria' in DB terms. I'll look into that. Maybe it'll be my chance to contribute to Rails core.
Distributed caching can be done with memcached or other caching frameworks. I don't see why it would need to be part of the framework. And I personally expect that using a native app, like memcached, is more powerful than mixing it into the system.
Finally, as far as time. You win. If what you say is true, and I totally believe it is, Rails is hard on the DB, apparently for no good reason.
JD
James,
HAML:
Err.. you think Adobe are going to invest their time and money to write a special parser for HAML? I don't think so. Dreamweaver knows how to deal with XHTML+CSS, not some weird custom format
Transactions:
Hibernate has a concept of a session which accumulates changes which are then flushed to the db at an appropriate point in time. This means you can have a conversation with the db that spans multiple requests where the changes are only commmitted maybe several requests later. All the time hibernate is rarely hitting the db.
I'm perfectly aware Rails supports db transactions, but container managed transaction spanning multiple requests is not, as far as I'm aware, possible.
Distributed caching:
With all due respect to memcache, having worked with it before it is a mere toy compared to some like Coherence with its features for transparent failover, multicast cluster management, entry processors, querying/filtering etc.
I do agree that it doesn't need to be part of the framework, all I'm saying is that the libraries in Java land are superior on multiple levels
Graeme, i think Masukomi makes a good point in his blog and writes more precisly what i paraphrased somewhat rough.
I don't doubt that Hibernate is in any way inferior to ActiveRecord but the whole bunch that RoR represents its imho much more usable (from a developers view) out of the box than Spring + Hibernate alone.
In a team with 3 people it's hard to choose the right technology if one must expect getting lost while configuring things in mess of xml files.
You wouldn't be working on Grails if there wouldn't be a wish or need among Java coders for something like rails. You quote Les Hazlewood with "I found Grails and it was like the heavens opening and angels singing "AAAAaaaaawh". I think he didn't discover anything new with Spring and Hibernate but saw that J2EE can be made a lot easier: Starting to write your closures and views instead of open your xml editor of choice just for configuring an app.
I didn't mean to flame with my post, really. I see myself in both worlds. For my own stuff (http://dailyfratze.de, a daily photo project) and some other private stuff i use RoR and i "love" it. Clearly, i don't need transaction spanning multiple request in this project.
At work we are heavily devoted to Java, both desktop apps and J2EE.
Kind regards from Germany,
Michael.
Like I told in my intial comment (see above) I really wanted to try out Rails. So I bought the obligatory books and started getting into it. Initially I was really impressed. Everything seems to be well thought out and seems to work hand-in-hand. No switching between all those different libraries, which come with different documentation, quality and philosophy.
My plan was to create an administration interface for an existing Sping/JPA webapp using Rails. So far I failed miserably:
I couldn't find a way to make ActiveRecord deal with my legacy database schema, which uses the "join" strategy to map a small simple class hierarchy to the database. I learned that ActiveRecords supports the "single table per class hierarchy" strategy only (which is a no-go in my case). This is really a showstopper for now. On my way learning I also noticed several other weaknesses of ActiveRecord (second-level cache missing and some other stuff). I wouldn't have thought that ActiveRecord is really that weak compared to Hibernate/JPA, since it is around for some years now.
Maybe I will try out Rails again when starting a complete new project. But for now my initial excitement about Rails yielded to disappointment.
I realize this post is a year old, but it deserves a follow-up :)
Setting up grails to use memcached is incredibly easy if you use the hibernate-memcached :) http://code.google.com/p/hibernate-memcached/
(end shameless plug)
Post a Comment