Sorry state of Tapestry
I still remember how about two years ago lazyboy and I spend an afternoon analysing pros and cons of various Java WEB frameworks. We were mostly choosing between Java Server Faces and Tapestry. We actually had a whiteboard and assigned points to various criteria such as open source community acceptance, syntax of meta files, testability etc. If I remember correctly the major strike against JSF was its lack of open source credentials (it was when My Faces were still before the first release). In the end Tapestry won, since lazyboy wanted to use it more than I wanted to use JSF. If I ever happen to have such discussion again, I will make sure to take into consideration release frequency.

I was never sorry sipXconfig chose Tapestry. We had a major success with it. We rewrote seemingly un-rewriteable network of JSP, javascript and godknowswhat code. We reduced the code size, accelerated development, took full advantage of component reuse. It was not automatic, but we even upgraded from Tapestry 3 to Tapestry 4 on the way, since we wanted to take advantage of the new features. I always knew that Tapestry is an ingenious rather than an elegant framework. To use it effectively in non-trivial applications you have to look under the hood all the time. You have to understand its vagaries and you have to learn to like them. If you prepare to invest in such relationship, you'll be rewarded. However unless something major changes in the Tapestry governance I feel like we are nearing the end of the road.

It is the well deserved right of project major contributors to run the project the way they see it fit. They can abandon community, write a new incompatible version, stop developing: there is nothing one can complain about. However the competitive edge that open source project enjoys lies in an ongoing dialogue with the users. When you stop regularly releasing the project the conversation breaks. Developers and users are speaking past one another. Developers are touting in-progress versions that users cannot deploy, users are asking for features and fixes in versions that developers have no intention to work on. It's no accident that agile methodologies with their release early and release often philosophy fit open source project better than a venerable plan, design, code, fix, release and pray approach. They promote this precious dialogue.

If you visit Tapestry website now, you will notice that there are 4 streams of development: 3.x, 4.0.x, 4.1.x, 5.x. 3.x is an outdated legacy, 4.0.x is the official release, 5.x is a bright new world. Both 4.1.x and 5.x are under development but without any road-map in place. It's been already discussed on Tapestry list that Tapestry 5 is going to be a major departure from Tapestry 4 (just as Tapestry 4 required a non-trivial transition from Tapestry 5). If you are starting a new project you have to use 4.0. But if you do that you agree that at some unspecified point in future you'll spend energy on rewriting you project to upgrade to Tapestry 5. Even if you happy with what 4.x is offering today and you are willing to stay with it for the rest of your project life (which is always longer than expected), you cannot count on regular bug fix releases. I am not saying the bugs are not getting fixed: they are - but only in the development branches you cannot upgrade to, since those branches do not have stable releases.

Again, there is really nothing wrong with having an experimental branch. I also think it's OK to fix bugs only in the latest stream that you consider stable. But you have to have a new, usable, stable release at least twice a year. Otherwise developers, users and contributors would look for a better place to channel creative energy.

The way we are using Tapestry evolves. I changed my mind diametrically on annotations. I used to think they make code too Tapestry centric and that meta information is better left in external XML file. I do not believe that any more: Java class that represents Tapestry page or component is already heavily Tapestry centric. You do not give up much if you allow annotations there. And it is easier to code and debug 2 files (.java and .html) rather than 3 (.java, .html and .page). This is the lesson I am probably ready to take to Hibernate and maybe even Spring annotations.

The other change is a new way of binding properties and parameters contained in tapestry-prop module. It ditches evaluating OGNL and uses byte code enhancement to achieve performance that rivals that of a native Java method call. I am not sure the performance gain is actually visible on most pages, but since I never liked having too much OGNL code, I want to give it a try.

Both annotations and tapestry-prop are great examples of what Tapestry could be: not just a framework but entire ecosystem of third party components, modules, editors and various development tools. But with the current approach to the development process I doubt it will ever realizes its potential.


- posted by Damian @ 7:23 AM | permalink