Tapestry 5 - Saviour of J2EE

Over the last few years I have been finding the state of Java Web development depressing. Java developers mostly use clunky and time consuming frameworks (such as struts) and struggle to deliver good quality and performant web sites. In the meantime tools such as RoR (or Groovy on Grails) have appeared and are used to deliver high quality (and sometimes even performant) websites. J2EE is in trouble - the mindshare among the 'cool' crowd is going. They have all moved onto new toys such as Rails. This is not an immediate problem for the vast bulk of the (corporate) J2EE developers out there, but it will become a problem as J2EE will become less competitive (.NET and RoR are waiting in the wings). The really depressing thing is Java has the tools to be as effective (if not more so) than Rails but people don't use them.

I have spent more than a few minutes thinking about the choice of frameworks and languages and I feel if I was able to specify the 'perfect' web framework it MUST have to

• Keep the developers focussed on writing pages and not on how/if the framework works
  
• Not require a large bespoke framework to be assembled around the framework. This is extremely common with competent, but not full featured frameworks such at Struts.
  
• Not have any major conceptual flaws - nothing is perfect, but some of the frameworks out there are just badly designed. It must be able to scale (e.g we can't process each request in full, we must be able to cache).
  
• Use the best techniques to reduce the overhead of configuration (e.g I don't want to define nearly the same thing in 17 XML files)
  
• Use a language or languages developers can understand
  
• When customisations /extensions are required allow a couple of developers to build them and the rest to use them, easily. 
  

It SHOULD

• Provide clear and precise error reporting
  
• Not hide HTML away - HTML is a fact of life, we need to be able to work with it. Designers design in it, the end user sees it and browser compatibility IS voodoo. It is not an incidental detail.
  
• Have detailed documentation regarding how to use, AND how it is assembled
  
• Provide tools to document our own site from what ever configuration it uses
  
• Provide rapid prototyping of pages (e.g. no need to restart the app server on each change)
  
• Provide tools to test your code/pages or integrate into those that already exist
  
• Let you reuse code in an efficient and sensible way
  
• Have an API that is powerful, easy to extend (so no horrible base class trees) and works
  

So tools like RoR go a long way towards meeting this goal. However I am not yet prepared to throw out Java with the current J2EE bath-water. Java is an excellent, typed language. It is easy to build fast clean code in it. I understand that scripting is attractive, but I simply don't see the point. The power of the current Java eco-system is that everything talks to Java. 

So presuming I stick with Java (as that is a much longer argument) I have come be believe the framework that delivers the above, today, is Tapestry 5. Rather than detail why it meets all of the above in this post I just want to pick a couple of highlights. I will then revisit this over the next few months.

So the top 3 features of T5

• Components - You can write genuinely reusable components. They work, if you have ever done ActiveX in Visual Basic think of how easy it was to use your controls across forms. The same is now (finally) true of the internet.
  
• Configuration (lack of) - I don't need ANY XML. It is annotations and/or naming conventions all the way. At last sanity has returned to java.
  
• Simplicity - The classes you write only do the bits you need. You don't need to worry about Request, Responses, HTTP. You simply write the page you are implementing. Most framework features are wired in, or activated by annotations. 
  

This is not the complete T5 sales pitch - but it gives a flavour. I will revisit some of the other key bits over the next few months.

This is the framework that could save J2EE from being a 'dull' and slow corporate tool and eventually fading as other toolsets come and replace it.