To add to what Alex has already said, IMHO the main difference between Grails and Tapestry is the so called "MVC architecture" vs component based architecture. Some developers are comfortable with the former while some prefer the latter and that is a very important factor for me.
I have worked on Rails, spring mvc like frameworks and I find myself writing a lot more code with these frameworks and I always miss the abstraction that components bring to the table. Also as Alex said, there may not be many ready to use plugins available for tapestry but it is really easy to create one. One way to find the answer to your question, if you have time :), is to create small reference apps with both your choices and you might find the answer before you complete the apps :) regards Taha On Oct 10, 2012, at 10:39 AM, Kalle Korhonen wrote: > Very clear and level-headed reasoning Alex. Would you like to, or > would you mind if I put it up as a blog post on tynamo.org? > > Kalle > > > On Tue, Oct 9, 2012 at 8:30 PM, Alex Kotchnev <akoch...@gmail.com> wrote: >> In the past five years, I worked on a number of greenfield projects. In >> three out of four, we ended up choosing Grails - it is very hard to deny >> the market & mindshare , the expansive documentation, the big name company >> behind the project, the large community, a massive number of plugins (for >> pretty much anything that you'd want), the end-to-end stack (so, you don't >> have to choose your ORM, DI, etc) and the ease of getting started with a >> Grails project. >> >> However, after working on a couple of these Grails projects for a few >> years, the latest project I got involved with , I chose Tapestry. In some >> cases, I've missed some of the niceties that Grails brings out of the box, >> but without too much effort I've been able to replicate them fairly easily. >> >> The biggest reasons for picking Tapestry over Grails on this latest project >> have been: >> 1. The inability to aggressively refactor your code - the dynamic nature of >> the language is nice when you want to knock something out quickly, and >> saves you a few lines of code here and there. However, after the codebase >> gets to a certain size, the inability to reliably refactor the codebase >> made the codebase difficult to evolve. Sure, IntelliJ & NetBeans has some >> support for refactorings in Groovy; however, it is not even close to the >> level of depth and ease of what you get with Java. I love Groovy to death, >> have been using it for many years (since it was in jsr-1 version) but ... >> the tool support is just not there yet (and likely will never be) and for a >> team of developers Java just ends up being a better choice (at least in the >> context of my team) >> >> 2. The importance of Tapestry components cannot be overstated. In a fairly >> modern web app, the functionality of each page depends on a bunch of >> markup, some CSS from a stylesheet, and some javascript from a javascript >> file. Tapestry makes putting everything together and using the results >> extremely easy and logical. In the late days of the last Grails project I >> was involved in, it was a massive PITA to build a page that really should >> have looked like 'that other one' - even when you used tag libraries to >> encapsulate the markup generation, you still had to hunt down all the css >> and js files that needed to be there. >> >> On the first issue, if you will be using Groovy for your pages, you will be >> in the same boat as Grails. Personally, I wouldn't recommend it - Tapestry >> already pushes the envelope on Java quite a bit, so your Java code ends up >> being very short and sweet already. In the past, I had attempted to use >> Scala in a tapestry app, and ended up having to just deal w/ some of the >> mismatches between the language and the framework and my pages ended up >> looking up like the same old java pages I would have had but with a >> different syntax. >> >> On the second issue, there is the grails resources plugin that tries to >> pull resources kinda like Tapestry, but using it requires this artificial >> separation into resource bundles which seems to be a PITA and somewhat mind >> bending. >> >> On the abundance of Grails plugins - after using a bunch for the projects I >> was working on, it turned out that many were not well maintained so we had >> to take over and maintain them ourselves. Sometimes, they're a good >> starting point, but in the end ended up less of a factor than I initially >> thought. >> >> I originally very much enjoyed the Grails build system (running on top of >> Gradle); however, with a pretty simple project setup, Maven seems to be >> just as straightforward. If you wanted Gradle, you could use that for your >> Tapestry app, and be on-par w/ Grails. >> >> On the latest project that I chose Tapestry for , I have been very happy >> with my choice. On a few occasions I've run into some frustrations (e.g. >> for rendering emails, I ended up having to use Freemarker, whereas with >> Grails the template rendering for emails comes for 'free' ; I had to build >> my own equivalent of the Grails "console" plugin where you can run Groovy >> commands inside of your running application); however, in all cases, the >> solution has turned out to be more elegant than I had expected (albeit, it >> required deeper tweaks in the framework than I had expected). >> >> Cheers, >> >> Alex Kochnev >> >> On Tue, Oct 9, 2012 at 4:17 PM, Thiago H de Paula Figueiredo < >> thiag...@gmail.com> wrote: >> >>> I haven't used Groovy myself, but it seems Tapestry and it work very well >>> for a long time. I've found a post by Howard Lewis Ship about this >>> combination in Tapestry 5.0.12, which was an alpha version, all that in >>> 2008: http://tapestryjava.blogspot.**com.br/2008/06/tapestry-with-** >>> groovy.html<http://tapestryjava.blogspot.com.br/2008/06/tapestry-with-groovy.html>. >>> Tapestry doesn't case about the language you use, as long as it generates >>> .class files and you put them in the right places. Some people has used >>> Tapestry with Scala too. >>> >>> >>> On Tue, 09 Oct 2012 16:39:16 -0300, scrotty <scro...@gmail.com> wrote: >>> >>> I am about to create a brand new website. I plan on using Groovy for my >>>> JVM >>>> language (just an arbitrary constraint I imposed on myself as part of the >>>> polyglot experience) and would like to give my users the niceties of AJAX >>>> on >>>> the front end. Everything else: DB, ORM, Web framework, etc. are wide >>>> open. >>>> >>>> I am not new to development in general nor web development in particular. >>>> I >>>> have development experience in all the layers typically used in a web >>>> application (from browser to DB). I am looking for technologies that will >>>> allow me to create and maintain a straight-forward web application while >>>> minimizing the "gotchas" that naturally occur when gluing each layer >>>> together. >>>> >>>> For web framework I've narrowed my candidates down to Grails and Tapestry >>>> and am leaning toward Tapestry. But it's hard for me to ignore the Groovy >>>> synergy in Grails. >>>> >>>> Does anyone have recommendations (especially - but not exclusively - if >>>> you've used Groovy with Tapestry) on which field I should plant my seeds >>>> in? >>>> >>>> Thank You! >>>> Sean >>>> >>>> >>>> >>>> -- >>>> View this message in context: http://tapestry.1045711.n5.** >>>> nabble.com/Greenfield-**development-Tapestry-or-**Grails-for-Groovy-dev-* >>>> *tp5716732.html<http://tapestry.1045711.n5.nabble.com/Greenfield-development-Tapestry-or-Grails-for-Groovy-dev-tp5716732.html> >>>> Sent from the Tapestry - User mailing list archive at Nabble.com. >>>> >>>> ------------------------------**------------------------------**--------- >>>> To unsubscribe, e-mail: >>>> users-unsubscribe@tapestry.**apache.org<users-unsubscr...@tapestry.apache.org> >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> >>> >>> ------------------------------**------------------------------**--------- >>> To unsubscribe, e-mail: >>> users-unsubscribe@tapestry.**apache.org<users-unsubscr...@tapestry.apache.org> >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
