Sean, I missed this in my original post, but Szemere's post reminded me of another issue w/ Grails.
Although I agree that at times, there is quite a bit of 'magic' that happens under the covers in Tapestry, it's nothing to the amount of magic that happens in Grails. For a seasoned java developer (with knowledge of all the underlying frameworks for grails - e.g. Hibernate, Spring, Sitemesh), getting started on a Grails project seemed like a very easy proposition - you just had to learn a few conventions here, a few magic method calls there, some mapping magic, some validation magic.. and it seemed easy. After working on the grails project for a while (and the team adding a few more layers of magic into the grails setup like service injection into any object in the app), we added a brand new developer to the team, and I realized how convoluted the thing had become. When I would attempt to help out with an issue, I'd catch myself having to know about multiple layers of 'magic' to explain how something works, which made the learning curve for Grails pretty steep as well, particularly for a 'new' developer. In the technology evaluation phase of the current project, I did exactly what was suggested a bit further up : I created two simple applications and added some basic functionality to showcase templating, validation, components/encapsulation, services, security and Grails and Tapestry were the front runners (not so far behind were Wicket and Play). On the maintainability of Grails application - technically, I'm sure you can make the application be as maintainable and as evolvable as a vanilla Java/Tapestry app. You could certainly write your domain/service model in Java and have great refactoring capability. If you want to take it a step further, you can even have the controllers in Java. It's just that the defaults you start with encourage the one-off approach to things and you end up paying for it down the line (which might be fine if the application you built turns out to be successful and maintenance-worthy). If you haven't already done so, I'd suggest posting a similar question on a Grails mailing list and see what kind of answers you get (I'd be curious about seeing them as well if you do so). Cheers, Alex K On Wed, Oct 10, 2012 at 4:46 AM, Szemere Szemere <[email protected]>wrote: > I've used both Tapestry (nearly 5 years) and Grails (1 year before junking > application). > > Grails has some really nice features, such as url mapping and the built-in > MVC framework. > > I didn't like: > 1) Lack of type-safety. Many errors would present themselves only at > runtime, which slowed productivity and in worst cases, resulted in errors > in production. > > 2) The incantations required to generate scaffolding - they are obscure and > require reading the manual in as much detail as just copy and pasting > similar code > > 3) Plugins and core system versions were often incompatible. This required > careful version management. > > Versus Tapestry, the +/-s > a) Tapestry has been rock solid and stable - very few critical bugs in the > core framework. Similarly with the limited plugins we use. > b) It's fairly complex to learn - particularly the request lifecycle and > IOC > c) Sometimes there's too much Java magic, which is hard to understand eg. > byte code enhancement of page classes > d) Does things its own way when a standard solution would have been easier > to understand and maintain eg. homegrown IOC. Wrt Tapestry IOC, I still > haven't got my head round the annotations on method parameters, together > with specially named parameters versus Guice's explicit Module constructor > w/ explicit bind calls. Tapestry methodology is too many steps of magic, as > opposed to simply leaving the one step of IOC object lookup and binding > magic - like the math prof who skips 2-3 steps of reasoning which are only > obvious if you know the technique well. > > In short, I would definitely recommend Tapestry above Grails, but I feel > that there is better yet to come in the web frameworks arena. > > Szemere >
