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).

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.

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?