Tapestry 5.0 Refcard: Meet The Author

Today DZone releases the Tapestry 5.0 Refcard, authored by Howard Lewis Ship - creator of Tapestry. To coincide with the release I got the chance to ask Howard some questions on Tapestry, it's future and his thoughts on software development in 2009.

James Sugrue: For those who don't know you, could you please introduce yourself?

Howard Lewis Ship: I'm Howard Lewis Ship, the creator of the Apache Tapestry framework. I've been active in the Java community since 1998, with my primary interests being web application development, dependency injection, meta-programming, and how this all fits together to improve developer productivity.

Download the Tapestry 5.0 Refcard

Sugrue: What problem does Tapestry solve? What motivated you to create the project?

Lewis Ship: Back around 2000, I was working on a project at Primix (a software consultancy in Boston) and I found that for all our emphasis on design and UML diagrams, we couldn't even agree on terms, never mind how to implement a big application, especially under time pressure. We wanted to talk about "the page" but all we could talk about was "the servlet" or "the JSP". Further, when we talked about other aspects of the application, we got caught up on issues of how to represent state stored in the session, or perhaps inside URLs ... you know the drill. This was in stark contrast to some prior demos I had written in Apple's WebObjects, which is the original component framework. WebObjects' core concept was to code in terms of objects and properties and let the framework figure out how to knit it all together. Those ideas flowed into the early versions of Tapestry used at Primix in 2001. Tapestry 1 is certainly stone knives and bear skins compared to Tapestry 5, but many of the core concepts, implemented quite differently, live on.

Sugrue: If I'm thinking about using a new UI layer in my web application, what are the cases that Tapestry is the right choice?

Lewis Ship: I'm quite willing to use Tapestry on anything from a single-page quickie up to applications with hundreds of pages and dozens of developers. It's designing for that kind of scalability. Tapestry is also very performant, partly because there's no runtime use of reflection, and partly because of the use of JDK 1.5 concurrency features. That being said, Tapestry isn't quite "Swing on the Web" and for that I'd investigate using Google Web Toolkit or Cappuccino, possibly in concert with Tapestry.

Sugrue: What is your top Tapestry tip?

Lewis Ship: Don't be afraid to write new components! It's easy, it's designed to be easy, and it can be a big win in terms of keeping a big application from getting bloated with code. You have a particular way you want to format a date? Write a component! You have a JavaScript-y client-side thing going on? Write a component! A useful Tapestry component can be anything from a single class and a couple of lines of code, up to a complex component with its own template, images and JavaScript.

Sugrue: This card is based on Tapestry 5.0 - what is planned for Tapestry 6.0?

Lewis Ship: Why would there be a Tapestry 6.0? Unlike prior versions of Tapestry, where I had to constantly make the difficult choice between new features and backwards compatibility, the total rewrite of Tapestry for Tapestry 5 was designed to allow new features and backwards compatibility. Partly this is due to the very good separation of user code from framework code, via naming conventions and annotations. Also, I've been careful to segregate the public parts of Tapestry (where backwards compatibility matters) from the internals.

That being said, there's lots afoot already in Tapestry 5.1 (currently in alpha). We've been beefing up the expression language. I found a lot of performance improvements throughout the framework (things that aren't visible unless you are building pages with thousands of components). Tapestry now automatically uses GZIP compression for clients that support it (that is, any modern web browser). I've improved the integration with Spring, so that you can now inject Tapestry services into Spring beans, as well as injecting Spring beans into Tapestry services and components. Improvements to localization support, improvements to the Tapestry Markup Templates, about 90 improvements and bug fixes so far (and Tapestry 5.0 was only released in December)!

On the drawing board for 5.1 or 5.2 is integrated support for Spring Web Flow, and for Tapestry applications deployed as Portlets. Those are the two most requested changes I get from talking to users. We're contemplating a switch from Prototype to jQuery on the client-side. A lot of the more advanced and interesting Ajax support can move from third-party libraries (such as ChenelleKit) into the framework itself. I've worked on a number of components for Formos' clients and some of those may be re-implemented as core components. For example, if you have a really dense, complex page with a lot of content, you may want to use progressive enhancement: drawing a simple placeholder on the initial render and immediately firing a request to the server to fill in the detailed content. That's the kind of thing that can be encapsulated inside a component. Another big request is skinning support, the ability to radically change the layout of a page based on any number of dynamic factors such as who the user is, or what particular data is shown.

Sugrue: What is the adoption of Tapestry like?

Lewis Ship: That's an open question that we don't have a lot of metrics for. At this point, I'd suspect that most "downloads" of Tapestry are coming out of the Maven repository, and even if that weren't true, it's quite hard to get download statistics from the Apache mirrors. You end up judging by the level of activity on the mailing list and other factors. Mostly, I get "pop ups" people who contact me, usually by e- mail, looking for a hand with a problem or to tell me about an application that just launched.

I've also gotten feedback that Tapestry is growing in popularity in Asia, possibly as a consequence of its exceptional internationalization support.

Sugrue: Did you enjoy writing the Refcard?

Lewis Ship: It was a lot of fun, and a real rush to see the first formatted version. It was painful trying to fit a useful amount of detail into six pages, though, and some things I wanted to include had to be dropped.

Sugrue: Are there any other Refcardz that you would recommend to developers?

Lewis Ship: I keep the Groovy one handy when I'm writing Groovy code.

Sugrue: What trends do you predict for 2009?

Lewis Ship: I think the economic downturn is going to be good for Open Source. I've definitely been seeing a shift in attitude: a few years ago, people treated any open source code with suspicion, as if it were a virus waiting to strike. I was on the phone with a client's lawyer once for an hour, explaining how Apache works top to bottom. Nowadays, Formos is seeing people come to us because we use and understand (and create!) open source and that's a trend I really want to see continue.

The other major trends is "The JVM is more than just Java". We've seen that with Groovy already ... a new language that operates within the JVM, a melding of Java and Ruby. We're seeing interest in other similar languages on the rise: Scala mixes Java with a Haskell-like type system, and Clojure (which I'm currenlty quite enamored with) brings Lisp and side-effect free functional programming into the JVM. These can be an uphill battle to bring into an organization, even though they are less difficult to learn than, say, a complex framework. I've been predicting for a couple of years that Java will become the language of interfaces and contracts, with implementations occurring in whatever language best fits.