|scrotty||Oct 9, 2012 12:39 pm|
|Lenny Primak||Oct 9, 2012 12:42 pm|
|Thiago H de Paula Figueiredo||Oct 9, 2012 1:17 pm|
|Alex Kotchnev||Oct 9, 2012 8:30 pm|
|Chris Mylonas||Oct 9, 2012 9:12 pm|
|Kalle Korhonen||Oct 9, 2012 10:09 pm|
|Lance Java||Oct 10, 2012 12:50 am|
|Taha Siddiqi||Oct 10, 2012 1:01 am|
|Szemere Szemere||Oct 10, 2012 1:46 am|
|Alex Kotchnev||Oct 10, 2012 7:01 am|
|scrotty||Oct 10, 2012 8:11 am|
|Subject:||Re: Greenfield development: Tapestry or Grails for Groovy dev?|
|From:||Alex Kotchnev (akoc...@gmail.com)|
|Date:||Oct 9, 2012 8:30:19 pm|
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)
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).
On Tue, Oct 9, 2012 at 4:17 PM, Thiago H de Paula Figueiredo < thia...@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.
-- Thiago H. de Paula Figueiredo