- What is the overall performance of your framework as it compares to others?
I haven't done any direct performance comparisons, but Tapestry 5 is considerably faster than Tapestry 4, which was already "fast enough". Using FireBug, I see that most requests (on my development machine) are on the order of 4 - 6 ms to process a request and get the response stream back; it takes the browser much longer to render the HTML up onto the screen. Tapestry uses no runtime reflection and doesn't appear to have any concurrency bottlenecks (the way OGNL can be in Tapestry 4).
- How does your web framework position themselves in relation to Web Beans?
Web Beans is one way of looking at how to manage state and process in a web application, but not the only one. Tapestry is already being used with Seam, and integration with Spring Web Flow will come some day (likely 5.1 as we're trying to get a stable 5.0 release out the door). Tapestry is in a good position to "embrace and extend" these kinds of specifications, since it doesn't care about anything but JavaBeans properties.
- How easy is it to create a re-useable component in your framework? Is it as easy as sub-classing an existing component?
You can subclass an existing component, but you can create a component as just a POJO with no inheritance. There's no configuration (other than putting it in the correct components package for your application). Bi-directional component parameters are as easy as placing a @Parameter annotation on a field. Components may have templates and may contain other components, it's all very consistent. It's always been easy to create components in Tapestry, but Tapestry 5 adds a number of features that make it even easier (such as no longer requiring you to select the correct base class). Further, it is much easier in Tapestry 5 to subclass a component and inherit its template and message catalog, but add new functionality. In addition, Tapestry 5 has the concept of Mixins, which provide another way to add new functionality to an existing component.
- What is the key differentiating characteristic of your framework that makes it better than the rest?
A ruthless emphasis on developer productivity drives nearly all the design decisions in Tapestry: this shows up with live class reloading, exceptional error reporting, adaptive APIs, and minimizing the amount of code (and markup) in an application. In terms of implementation, Tapestry embraces pervasive object orientation (not just inheritance), meaning lots of small focused objects able to work together seamlessly.
- What do you think about the various scopes introduced by Seam, e.g. conversation vs request or session? If you support these additional scopes, do you also provide some sort of concurrency control?
These are very important; Tapestry already has a number of ways of managing server-side state; individual page or component fields may be stored on the client, rather than in the session, for example. As with much of T5, the support is cleanly extensible, so natively supporting conversational state without using Seam is a possibility, as is leverage Seam itself (there's an add-on library for this), as are many other options.
- Why can't we, the Java Community, come together and adopt the best application framework and settle the web development subject?
That's like saying, "Why can't we, the developer community, come together and adopt the best language?". Generally, people with a lot of experience in one framework are looking for a bigger, badder version of their framework, that also magically solves all their problems ... especially those caused by their choice of framework. Sometimes it's the craptaculous framework. Often the fix is something is a completely different vein (and Tapestry has always been that different vein). It's kind of like the adage about a council of Great Apes designing their evolutionary successor. They'd probably come up with a bigger, stronger Ape ... not a scrawny, weak, hairless human.
- What are you doing to help with developer productivity?
Tapestry is primarily focused on developer productivity, and this should not be confused with simply adding tool support (and dealing with wizard-generated code). Tapestry addresses the needs of developers to build applications using simple, off the shelf tools, such as Java IDEs and standard XML editors. Tapestry has best-of-breed exception reporting. This is more than a fancy exception report page; it's also attention to detail throughout the framework to catch problems and report them in a useful manner to the developer. For example, if you use the wrong name when defining a component or referencing a page, Tapestry doesn't just throw a NullPointerException the way too many libraries would; it clearly identifies the line in your template with the problem, identifies the name you gave, and provides a list of possible values to help you make the correction. Oh, and it's generally case insensitive. Add live class reloading on top of this, and you can burn through your application very quickly. In fact, Tapestry addresses developer productivity by making the development more Fun and less of a Drudge.
- 2008 is a huge year for the mobile web. How do you help developers build great mobile web applications?
Size counts on the mobile web and Tapestry has been built with terseness as a virtue. URLs are shorter and more readable, page content is simpler, and many components include a "lean" mode to reduce optional content generation (such as CSS classes inside the Grid component).
- If you couldn't use your framework, what would you use and why?
I'd be very interested in learning to really leverage Adobe's Flex ... if I can't use Tapestry, I want something that gives me pixel-level control and good abstraction without the kludges and half measures of JavaScript and the DOM.
- How do you enable rich Ajax applications?
Tapestry supports very clean interactions between the client and the server, as server-side components can easily be referenced via a URL. Handling Ajax requests in Tapestry is virtually identical to handling of traditional page-oriented requests. A limited amount of base support is provided in the framework (text field autocompletion, dynamic content zones, extensible forms) with much more support provided by the community. Currently Ajax support is a wrapper on top of Prototype/Scriptaculous and there is great desire to make the client-side support more agnostic.
- Can a developer make a change to source, and hit RELOAD in the browser to see the change? If not, why not?
Absolutely. I think Tapestry was on the cutting edge nearly two years ago when this feature was introduced in early versions of Tapestry 5; other frameworks are still trying to catch up. This feature is critical to developer productivity and making it fun. Further, Tapestry's approach to server-side state means that persistent data is not lost on reload, which significantly enhances the developer's ability to continue work from where they left off. Tapestry is even pretty good about picking up the addition of new pages and components, not just updates to existing Java classes.
- What do you think about the whole Flex revolution, and do you think you are competitors to this technology?
Flex is an impressive piece of work, and it gives you quite a lot of power. Still, I think RIAs (such as Flex) are in a parallel, not competing, category against traditional web applications (even those enhanced with Ajax) . Tapestry has an emphasis on bookmarkable URLs, and though Flex supports this feature, there are some costs and limitations. I don't want to spread FUD, but to me a Flex application is pretty heavy weight ... big enough to require a loading screen, whereas a web application just pops up instantly. I haven't pushed myself far enough up the Flex learning curve to talk in more detail. I tend to discount the "Grandma factor": that is, Flash is almost certainly already installed on Grandma's computer. Even so, Flex's greatest strength and greatest weakness is the proprietary Flash runtime: even more than Sun, Adobe is protective of their runtime environment, and fearful of splintering. This is increasingly unsettling to developers used to full open source everything.
P.S. I'm sure James Ward will correct everything I've just stated.
- How easy is it to create a module and plug it into a bigger application, complete with configuration, code, and view?
Really, really easy. Choose a package name, put your pages, components, base classes, etc. in sub-packages, along with any templates. Create a module class for your library to provide Tapestry with configuration for the module's package. One tweak to your Ant or Maven build script to enable autoloading of the module, at which point it Just Works. Tapestry takes care of all sorts of issues, including providing secure and efficient client-side access to assets (images, stylesheets, etc.) packaged inside your library's JAR.
