Java Web Frameworks - What Lies Ahead
There has been a lot of talk recently about the future of Java web application frameworks. There has been a noticeable mind shift from the view that simple action-based web MVC frameworks such as Struts and MVC are sufficient. Increasingly, the view held is that this is no longer the case, and that the potential gains to be had from a component based framework are too great to ignore.
Part of this is due to the arrival of JSF, the new official standard for a component-based web application framework and the Java world's response to ASP.NET. OK, its not brand new - the spec was released in May last year - but now there are implementations and increasing interest among developers. JSF is guaranteed its fare share of converts because its seen as the natural successor to Struts, partly because the original Struts developer is a JSF spec lead, and partly because Struts itself is going into maintenance mode, to be replaced by Struts Shale - a JSF implementation.
Java developers are also looking at what else is out there. After a long period of rather quietly being developed and adopted by a fairly small band of enthusiasts, Tapestry is now being noticed. The logic is: OK, if I'm going to go down the JSF route, lets take a look at what else is out there.
The big advantage Tapestry has over JSF is the fact that you can use it with whizzywig authoring tools. That makes it a great solution if Java developers have to work together with web desginers. For JSF, you need special JSF-specific tools, which web designers would not be comfortable or familiar with.
I was put off Struts from the very beginning by the fact that all the HTML tags are replaced by JSP custom tags. Unfortunately JSF has gone down the same route. I'd expect Tapestry to perform better than any equivalent JSF app as a result. From what I know about JSF (not much admittedly - I'm still waiting for my book to arrive from the amazon.com), your web application classes (JavaBeans) are relatively free from dependencies from the framework itself, which makes it easier to test and develop apps in isolation.
Tapestry components must subclass Tapestry framework base classes - something which appears to be on the horizon to fix but still an architecture rework. Personally, of the two shortcomings, I think I can more easily live with Tapestry's. There is also great value in a mature stable implementations as against a spec with not yet mature implementations.
My guess is that JSF (+ good tool support) will offer best value for RAD development where precise control over look and feel is less important (e.g. intranet apps) and where performance is not that critical. For high volume internet apps with where good design is crucial I'd expect Tapestry to be a superior technical choice.