This post originated from an RSS feed registered with Java Buzz
by Warner Onstine.
Original Post: Tapestry future (adoption redux)
Feed Title: Tapestry Live
Feed URL: http://www.jroller.com/WarnerOnstine/feed/entries/rss
Feed Description: Home of the Tapestry Live book by Warner Onstine.
First, I would like to thank everyone who took the time to respond to my original post, it definitely was enlightening. Here is my redux on the adoption of Tapestry post I made a little more than a week ago. It does seem that most people seemed to agree with me on what was probably the biggest reason why I see the Tapestry adoption rate as being so low – constant changes in the framework from version to version. One shining point came from Howard himself
Further, the design of Tapestry 5 was created specifically to make it possible to continue adding features without breaking backwards compatibility going forward. There will not need to be a Tapestry 6.
I found this to be one of the best responses out there and I definitely salute it. I have been watching Howard's screencasts on Tapestry 5 which have some very cool ideas in them.
Others seem to think that JSF, Rails and Grails were not serious contenders (or irrelevant), and they are certainly welcome to their views, but I disagree. All Web frameworks are going to be contending with each other for our mindshare as developers. And where developers go, so must the organizations. You get enough developers saying that they should be using “X“ then they need to start taking notice. Now, if they meant they were irrelevant to the discussion at hand (Tapestry‘s adoption) then I have to disagree as well. I‘ve seen organizations choose JSF over Tapestry simply because it is the big gorilla, not because it is technically better (and there was no investigation, just a recommendation from someone). I‘ve also seen individual developers move from Tapestry to Rails and where the hearts and minds go, so go the people.
Alright, moving on from the comments to something positive, where do I think things need to head in order for Tapestry to be at the top of the list again?
Make it easy and fun to write Web apps: most of these aren‘t fun, but writing them should be and the framework shouldn‘t be the challenge, the app should be
Configuration should be simple: I think that Tapestry 5 is heading in this direction already
Routing should be dead simple: friendly URLs or REST URLs should be easy to configure. I know it will be simpler in Tapestry 5, but it would be nice to have a routing DSL that makes it easy to just drop in without having to do what I did for the Events Calendar app, that was a pain
Services should be simple: one of the biggest things to get your head around in Tapestry 4 was HiveMind and making a new “service“ type (for catching URLs and doing stuff with them, see routing DSL above which will help with this)
Make it easy to do new view layers: Even though I initially agreed with the Tapestry tenet that “HTML is King” I have begun to shift away from that and it would be great if I could write my own (or use another) View layer besides the HTML document. Provide easy hooks so that developers can do things like this easily. This is one area where I think JSF has gained over Tapestry.
Groovy everywhere ;-): now that Groovy supports annotations and support for generics is going in it would be great if I could use Groovy in as many places as I care too. I know this is definitely doable in the page layer (I can create a simple POJO with annotations) but I (of course) want more!
DSLs: I would love to see a shift away from things that make it easier for the framework to handle (such as an XML config file) to something that makes my life easier (like a custom DSL). This is definitely a shift in thinking, but one that makes Rails so much easier to develop in (and one reason why I think Grails is doing so well). Stop thinking about the framework and start thinking about the end user – the developer.
A component “marketplace”: I really like this idea but for one reason or another it hasn‘t taken off. One reason for this is that it wasn‘t dead simple to just drop these in and go (say with a Maven repo). If I get some time I want to revive the idea of Tassel and have some ideas on this, but I think that I would like to revive it as a Tapestry 5 app, which means waiting a bit (and waiting because I have no time). But this needs a Maven repo attached to it so that it is dead simple to include at build time and would provide a managed area for versions.
Community: I would love to see something like Groovy blogs for Tapestry, again something that I would like to actually pair with the revamped Tapestry components repository.
Wow, OK, that‘s probably about it, would love to hear others‘ thoughts on this as well!
Previous Topic
