For his Web Framework Smackdown event at TheServerSide conference, Matt Raible posted a list of questions that people wanted to know about each framework.
Tapestry already responded and I think there is merit in answering these questions for developers to quickly gauge if a particular framework fits their needs.
- Q1: What is the overall performance of your framework as it compares to others?
There is a FAQ topic on performance which outlines the amount of work done by Click per request. In short it creates a small amount of short lived objects and uses very little reflection. For rendering Click uses a non-blocking string buffer and estimates the output size to avoid unnecessary memory allocation and arraycopy operations.
I also ran a benchmark to test how fast Click was in practice. The benchmark used was adopted from a similar effort started by Apache Wicket and can be downloaded here.
It tests the performance of rendering a Table consisting of 50 rows by 5 columns. There is no database involved. The data is randomly generated at the start of the application and served statically.
On a dual core Dell Laptop, 32-bit, T2600 @ 2.0 GHz, Tomcat 6.0.13, -Xmx512m, Windows XP, JDK6 the results for Click was:
~400 requests per second.
On a core 2 duo desktop PC, 64-bit, E8400 @ 3.0 GHz, Tomcat 6.0.13, -Xmx512m, Linux Ubunutu, JDK6 the results for Click was:
~1500 requests per second.
On a proper server I doubt Click will ever be the bottleneck.
It is worth mentioning that Click is a stateless component oriented framework, thus scalability should be as easy (or difficult) to achieve as with an action oriented framework. - Q2: How does your web framework position themselves in relation to Web Beans?
From my understanding Web Beans is targeted at JSF and EJB3. There is no relation to Click. - Q3: How easy is it to create a re-useable component in your framework? Is it as easy as sub-classing an existing component?
Components are written in Java so it is straightforward to write new ones. Either implement the Control interface or extend one of the existing controls.
For example if you want to have a link that always references your home page, you can extend the PageLink (which enables linking to specific pages) and override the #getPageLink() method to return HomePage.class. Here is the code:public HomeLink extends PageLink {
public HomeLink() {
setName("Home");
}
// Overridden to always return home page.
public Class getPageClass() {
return HomePage.class;
}
} - Q4: What is the key differentiating characteristic of your framework that makes it better than the rest?
In short: simplicity. However since all frameworks promote simplicity as one of their benefits let me elaborate a bit.
Click's simplicity and ease of use are realized through a lack of complex abstractions.
Have a look at the core and extras API to see what I mean.
There are very few interfaces and abstract classes. Click's target audience is the application developer who has limited time to spent learning new frameworks. Click focuses on solving actual problems instead of adding new buzzwords to its feature list. - Q5: 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?
I'll answer these questions separately.- 5.1: Perhaps I am showing my ignorance here but it seems conversation scope tries to solve a problem invented by JSF?
I would argue that one should not try and be too smart about this. Stick to what has always worked well: after each request save the state to the database and enjoy your Saturday evening at the theater, as you won't have any problems to worry about. - 5.2: Click does not support conversation scope as outlined by Seam. However the traditional way of having a conversation scope is by passing variables inside hidden fields or as hyperlink parameters.
To see this in action have a look at the table paging and sorting example.
If you open a couple of tabs you will notice that the table sorting and paging does not interfere with one another. This way of handling conversation works really well and keeps your session free of state.
- 5.1: Perhaps I am showing my ignorance here but it seems conversation scope tries to solve a problem invented by JSF?
- Q6: Why can't we, the Java Community, come together and adopt the best application framework and settle the web development subject?
We already did it once before with Struts so I guess it is possible. But back then Struts was the only option and the choice was easy. I think it will be difficult to find a framework which satisfies everybody in every industry. Some folks like standardization, others like simplicity and yet others like sophisticated frameworks. - Q7: What are you doing to help with developer productivity?
Click tries to help with productivity as follows:- From a design perspective Click is as simple as possible.
- Good documentation explains the design clearly.
- Components know how to draw themselves which alleviates the developer from maintaining redundant markup. Meaning if you define a Table or Form in your Page, you won't have to redefine that component in your template.
- Use convention over configuration.
- Great error reporting both in the logs and browser.
- Lots of examples and best practices to learn from.
- Q8: 2008 is a huge year for the mobile web. How do you help developers build great mobile web applications?
Not really my field of expertise but Click does not in any way hinder the building of mobile applications. - Q9: If you couldn't use your framework, what would you use and why?
I will use an action based framework, probably Stripes. Stripes is well documented and seems easy to learn and understand. It uses convention over configuration and focuses on the common problems instead of the exceptions. - Q10: How do you enable rich Ajax applications?
Click supports clean URL's thus making callbacks from your favorite Ajax library is straightforward. You can also create custom Ajax components that deploy their own javascript libraries at runtime. - Q11: Can a developer make a change to source, and hit RELOAD in the browser to see the change? If not, why not?
Click uses Velocity or JSP for templating. Both will reload a template if it changes.
However components and pages does not support auto reloading when they are recompiled. There are some code lying around that enables this feature by using the parent last ClassLoader trick, but it has not been integrated into trunk yet.
One snag with automatic reloading is that it ends up as an advanced feature because web frameworks cannot make it transparent. For example we can reload Click pages and components, but not Hibernate entities or Spring configuration changes. In the end the developer has to understand Java ClassLoading issues and why certain changes are not refreshed.
I am hoping that the JVM can someday solve reloading natively. There is in fact a RFE filed for this: RFE 4910812
On the commercial side JavaRebel claims to have solved the issue at the JVM level already. Sounds good to me! - Q12: What do you think about the whole Flex revolution, and do you think you are competitors to this technology?
Flex + Flash are great technologies for building rich applications. On the other hand so is Swing, Eclipse and Netbeans RCP. All depends on the clients need really.
Since Flex is client side and Click server side, I don't see much overlap. One can certainly use them together. ;-) - Q13: How easy is it to create a module and plug it into a bigger application, complete with configuration, code, and view?
This feature is not available yet but scheduled for the next release.
