What web platform is right for me?

Question

I've been looking at web frameworks like Rails, Grails, etc. I'm used to doing applications in Spring Framework with Hibernate... and I want something more productive.

One of the things I realized is that while some of the things in Grails is sexy, there are some serious problems with it. Grails' controllers:

1) are implemented awfully. They don't seem to be able to extend from super classes at runtime. I tried this to add base actions and helper methods, and this seems to cause grails to blow up.

2) are based on an obsolete request parameters model (rather than form backing objects, which are much nicer).

3) are hard to test. Command objects are treated totally differently... and it's actually MUCH harder to write the test than it is to write the controller code.

4) Command objects operate totally differently. They are pre-validated and bound, which causes a lot of inconsistencies than basic parameter model.

5) Command objects are not reusable, and it's a pain in the rear to reuse most of the stuff from the domain classes, like constraints and fields. This is TRIVIAL to do in basic Spring. Why the hell was it not trivial to do in Grails?

6) The scaffolding that is generated is pure crap. It doesn't generalize inserts and updates... and it actually copy/pastes a pile of code in two views: create.gsp and edit.gsp. The views themselves are gargantuan piles of doggie do-do. This is further compounded by the fact that it uses low-level parameters and not objects.

Integration tests are 30x slower than a Spring integration test. It is disgusting.

Some mocking tests are so hard to write and aren't guaranteed to work when it's deployed, that I think it discourages fast, tdd test cycles.

Most things seem to screw up grails while it's running, like adding a taglib, or anything really. The server restart problem wasn't solved at all.

I'm starting to think going with Spring/Hibernate/Java is the only way to go. While there is a pretty big cost at startup, I know it'll eventually smooth out.

It sucks I can't use a language like Scala... because idiomatically, it is so incompatible with Hibernate.

This app is also not a run-of-the-mill UI over a database. It's got some of that, but it's not going to be a slouch. I am deathly scared of Grails now because of how crap it is in the Controller layer.

Suggestions on what I can do?

Answer 1

All abstractions leak. You name six items on the contra side for grails. One for Spring. It seems, you'd prefer Spring, then.

Answer 2

You could checkout the Play! framework. I'm currently working on an application in grails that seems to be going well and haven't really done much with the play framework so it may or may not work for you. One of the recent additions to the play framework is the Scala module which allows you to code in Scala.

Answer 3

I'm starting to think going with Spring/Hibernate/Java is the only way to go. While there is a pretty big cost at startup, I know it'll eventually smooth out.

Then maybe have a look at Spring Roo (also read Grails vs Roo - why SpringSource is pushing two very similar technologies?).

Answer 4

I've been using Grails on a couple of projects over the past year and have found that the development productivity gains far outweigh the cons, and I haven't found a con that I couldn't work around.

Regarding some of your specific objections:

1) are implemented awfully. They don't seem to be able to extend from super classes at runtime. I tried this to add base actions and helper methods, and this seems to cause grails to blow up.

FWIW, I've never felt the need to extend the controller from a base class. Each controller supports specific HTTP calls that don't lend themselves to reuse, and anything needed reuse can/should be delegated to a service.

2) are based on an obsolete request parameters model (rather than form backing objects, which are much nicer).

Again, FWIW this hasn't been an issue for me. Grails packages all the params nicely into a Map, which is all I usually need. If I need more, I create a Command object, which is pretty straightforward.

3) are hard to test. Command objects are treated totally differently... and it's actually MUCH harder to write the test than it is to write the controller code.

Yep- testing in grails is one of it's low points. I've abandoned Grails test harnesses completely and just use Selenium to automate testing via the GUI. Not ideal, but it's worked fine for us.

6) The scaffolding that is generated is pure crap. It doesn't generalize inserts and updates... and it actually copy/pastes a pile of code in two views: create.gsp and edit.gsp. The views themselves are gargantuan piles of doggie do-do. This is further compounded by the fact that it uses low-level parameters and not objects.

I've actually found the scaffolding to be pretty helpful in getting started. It never makes it to production in it's native form (except occasionally for internal apps), but it saves a ton of time getting started developing basic building blocks of your app. Also, you can always create your own scaffolding templates if you don't like the provided ones.

Integration tests are 30x slower than a Spring integration test. It is disgusting.

Some mocking tests are so hard to write and aren't guaranteed to work when it's deployed, that I think it discourages fast, tdd test cycles.

Again, yes- testing is not Grails strong suit.

Most things seem to screw up grails while it's running, like adding a taglib, or anything really. The server restart problem wasn't solved at all.

I haven't had any issues in this areas since 1.2 came out. It's the cleanest change-while-running environment I've worked with. Certainly there are some things that require a restart (e.g. mods to bootstrap), but for most stages of development it works great.

I'm starting to think going with Spring/Hibernate/Java is the only way to go. While there is a pretty big cost at startup, I know it'll eventually smooth out.

Not only at startup, but all through the development process. I'm guessing that the teams I'm working with are producing production-ready features at a rate of 3-5x as fast as we could have using "traditional" frameworks. It's certainly not for everyone and every project, and it is not perfect, but it can be a huge accelerator if you're project fits into Grails strengths. Add to that the fact that you can largely pick and choose how much Grails you want to use (vs. tapping into Spring/J2EE layers if you want), and I see it as a "have your cake and eat it too" option. My 2c.