Raible Designs

How I Calculated Ratings for My JVM Web Frameworks Comparison

When I re-wrote my Comparing JVM Web Frameworks presentation from scratch, I decided to add a matrix that allows you to rate a framework based on 20 different criteria. The reason I did this was because I'd used this method when choosing an Ajax framework for Evite last year. The matrix seemed to work well for selecting the top 5 frameworks, but it also inspired a lot of discussion in the community that my ratings were wrong.

I expected this, as I certainly don't know every framework as well as I'd like. The mistake I made was asking for the community to provide feedback on my ratings without describing how I arrived at them. From Peter Thomas's blog:

What you are doing is adjusting ratings based on who in the community shouts the loudest. I can't help saying that this approach comes across as highly arrogant and condescending, you seem to expect framework developers and proponents to rush over and fawn over you to get better ratings, like waiters in a restaurant trying to impress a food-critic for Michelin stars.

I apologize for giving this impression. It certainly wasn't my intent. By having simple numbers (1.0 == framework does well, 0.5 == framework is OK and 0 == framework not good at criteria) with no rationalization, I can see how the matrix can be interpreted as useless (or to put it bluntly, as something you should wipe your ass with). I don't blame folks for getting angry.

For my Rich Web Experience presentation, I documented why I gave each framework the rating I did. Hopefully this will allow folks to critique my ratings more constructively and I can make the numbers more accurate. You can view this document below or on Google Docs.

In the end, what I was hoping to do with this matrix was to simply highlight a technique for choosing a web framework. Furthermore, I think adding a "weight" to each criteria is important because things like books often aren't as important as REST support. To show how this might be done, I added a second sheet to the matrix and made up some weighting numbers. I'd expect anyone that wants to use this to downloaded the matrix, verify the ratings are accurate for your beliefs and weight the criteria accordingly.

Of course, as I and many others have said, the best way to choose a web framework is to try them yourself. I emphasized this at the end of my presentation with the following two slides.

My Comparing JVM Web Frameworks Presentation from Devoxx 2010

This week, I've been having a great time in Antwerp, Belgium at the Devoxx Conference. This morning, I had the pleasure of delivering my Comparing JVM Web Frameworks talk. I thoroughly enjoyed giving this presentation, especially to such a large audience. You can view the presentation below (if you have Flash installed) or download it here.

Unlike previous years, I chose to come up with a spreadsheet matrix that shows why I chose the 5 I did. This spreadsheet and rankings given to each framework are likely to be debated, as I don't know all the frameworks as well as I'd like to. Also, the missing column on this spreadsheet is a "weighting" column where you can prioritize certain criteria like I've done in the past when Comparing Ajax Frameworks. If you believe there are incorrect numbers, please let me know and I'll try to get those fixed before I do this talk again at The Rich Web Experience.

One thing that doesn't come across in this presentation is that I believe anyone can use this matrix, and weightings, to make any of these frameworks come out on top. I also believe web frameworks are like spaghetti sauce in The Ketchup Conundrum. That is, the only way to make more happy spaghetti sauce lovers was to make more types of spaghetti sauce. You can read more about this in my There is no "best" web framework article.

Update: If you disagree with the various ratings I gave to web frameworks in this presentation, please provide your opinions by filling out this survey. Thanks to Sebastien Arbogast for setting this up.

Update: Sebastien has posted his survey results at JVM Web Framework Survey, First Results.

Update 12/6: A video of this presentation is now available on Parleys.com.

P.S. My current gig is ending in mid-December. If you're looking for a UI Architect with a passion for open source frameworks, please let me know.

AppFuse 2.1 Milestone 2 Released

I'm pleased to announce the 2nd milestone release of AppFuse 2.1. This release includes upgrades to all dependencies to bring them up-to-date with their latest releases. Most notable are Spring 3 and Struts 2.1. This release fixes many issues with archetypes and contains many improvements to support Maven 3. For more details on specific changes see the 2.1.0 M2 release notes.

What is AppFuse?
AppFuse is an open source project and application that uses open source frameworks to help you develop Web applications quickly and efficiently. It was originally developed to eliminate the ramp-up time when building new web applications. At its core, AppFuse is a project skeleton, similar to the one that's created by your IDE when you click through a wizard to create a new web project. If you use JRebel with AppFuse, you can achieve zero-turnaround in your project and develop features without restarting the server.

Release Details
Archetypes now include all the source for the web modules so using jetty:run and your IDE will work much smoother now. The backend is still embedded in JARs, enabling you to choose with persistence framework (Hibernate, iBATIS or JPA) you'd like to use. If you want to modify the source for that, add the core classes to your project or run "appfuse:full-source".

AppFuse comes in a number of different flavors. It offers "light", "basic" and "modular" and archetypes. Light archetypes use an embedded H2 database and contain a simple CRUD example. In the final 2.1.0 release, the light archetypes will allow code generation like the basic and modular archetypes. Basic archetypes have web services using CXF, authentication from Spring Security and features including signup, login, file upload and CSS theming. Modular archetypes are similar to basic archetypes, except they have multiple modules which allows you to separate your services from your web project.

AppFuse provides archetypes for JSF, Spring MVC, Struts 2 and Tapestry 5. The light archetypes are available for these frameworks, as well as for Spring MVC + FreeMarker, Stripes and Wicket.

Please note that this release does not contain updates to the documentation. Code generation will work, but it's likely that some content in the tutorials won't match. For example, you can use annotations (vs. XML) for Spring MVC and Tapestry is a whole new framework. I'll be working on documentation over the next several weeks in preparation for the 2.1 final release.

For information on creating a new project, please see the QuickStart Guide.

If you have questions about AppFuse, please read the FAQ or join the user mailing list. If you find bugs, please create an issue in JIRA.

Thanks to everyone for their help contributing patches, writing documentation and participating on the mailing lists.

AppFuse 2.1 Milestone 1 Released

The AppFuse Team is pleased to announce the first milestone release of AppFuse 2.1. This release includes upgrades to all dependencies to bring them up-to-date with their latest releases. Most notable are Hibernate, Spring and Tapestry 5.

What is AppFuse?
AppFuse is an open source project and application that uses open source tools built on the Java platform to help you develop Web applications quickly and efficiently. It was originally developed to eliminate the ramp-up time found when building new web applications for customers. At its core, AppFuse is a project skeleton, similar to the one that's created by your IDE when you click through a wizard to create a new web project.

Release Details
Archetypes now include all the source for the web modules so using jetty:run and your IDE will work much smoother now. The backend is still embedded in JARs, enabling you to choose which persistence framework (Hibernate, iBATIS or JPA) you'd like to use. If you want to modify the source for that, add the core classes to your project or run appfuse:full-source.

In addition, AppFuse Light has been converted to Maven and has archetypes available. AppFuse provides archetypes for JSF, Spring MVC, Struts 2 and Tapestry 5. The light archetypes are available for these frameworks, as well as for Spring MVC + FreeMarker, Stripes and Wicket.

Other notable improvements:

• Added Compass support thanks to a patch from Shay Banon.
• Upgraded from XFire to CXF for Web Services.
• Moved Maven repository to Sonatype's OSS Repository Hosting for snapshots and releasing to Maven Central. There are no longer any AppFuse-specific artifacts, all are available in central. Thanks to Sonatype for this great service and its excellent repository manager.
• Upgraded to Canoo WebTest 3.0. Now if we could just get its Maven Plugin moved to Codehaus.
• Added Ajaxified Body to AppFuse Light archetypes.
• Infrastructure upgrades, including JIRA 4, Confluence 3, FishEye 2, Bamboo 2 and Crowd 1.6. Many thanks to Atlassian and Contegix for their excellent products and services.
• For more details on specific changes see the release notes.

Please note that this release does not contain updates to the documentation. Code generation will work, but it's likely that some content in the tutorials won't match. For example, you can use annotations (vs. XML) for dependency injection and Tapestry is a whole new framework. I'll be working on documentation over the next several weeks in preparation for Milestone 2.

AppFuse is available as several Maven archetypes. For information on creating a new project, please see the QuickStart Guide.

To learn more about AppFuse, please read Ryan Withers' Igniting your applications with AppFuse.

The 2.x series of AppFuse has a minimum requirement of the following specification versions:

• Java Servlet 2.4 and JSP 2.0 (2.1 for JSF)
• Java 5+

If you have questions about AppFuse, please read the FAQ or join the user mailing list. If you find bugs, please create an issue in JIRA.

Thanks to everyone for their help contributing code, writing documentation, posting to the mailing lists, and logging issues.

Dojo/Comet support in Java Web Frameworks

This week I'm doing a research project for a client. The main purpose of the project is to find out which Java-based web framework works best with Dojo and Comet. Here's the key requirement from the client:

It's all about Comet, we want Comet everywhere we can put it, but we want to isolate the icky bits of fiddling with pages with JavaScript. We're kind of wed to the Dojo implementation of the client-side bit, so we may as well use more of the Dojo widgets for a richer UI. For us, "works best with" needs to pay a certain amount of consideration to "fits naturally with", if you understand what I mean. I know that any framework that lets you spit out raw HTML will let you hand code in your Dojo / Comet, but that's certain to become very tiresome very quickly.

The candidate frameworks they asked me to look at are Wicket and Tapestry 5. They're willing to upgrade to Struts 2 since they're already using Struts 1. However, they don't feel that action-based frameworks naturally lead to rich UIs, so they'd prefer a component-based framework. They're currently using Seam for an administration-type application and feel it's too heavy for their customer-facing application.

Here's what I've found so far in my research. Please let me know if anything is incorrect.

• Tapestry 5 doesn't have Dojo or Comet support (Prototype and Scriptaculous are the baked-in Ajax frameworks).
• Struts 2 has old (version 0.4.3) and somewhat deprecated Dojo support. The developers seem to be in favor of removing it and promoting people hand-code Dojo instead. Struts 2 doesn't have support for Comet.
• Wicket has support for Dojo 1.1 that includes Comet support. This was written by Stefan Fußenegger and posted to the mailing list last month. I e-mailed Stefan and asked him about documentation. His response: "I lost my ambition to document it properly since I didn't receive any feedback on the mailing list. :)"

At this point, it seems that if the client really wants to use Dojo, they should use Wicket, and possibly pay Stefan to document it properly. However, they're willing to consider other options, as long as they have Comet support.

One option I thought of is to use DWR and its Reverse Ajax/Comet support. Another option would be to add better Dojo support to Tapestry 5. However, I don't think this is possible since the Prototype/Scriptaculous code is generated by the framework and would likely require a changes to switch it to Dojo.

Are there any other Java-based web frameworks that support easily creating Dojo widgets and working with Comet? Keith Donald tweeted that Spring MVC has Dojo support. However, I believe it's only for widgets and it still requires you to write JavaScript. If your framework doesn't have Dojo/Comet support, how hard would it be to add it?

Update: I also posted this question on LinkedIn. Make sure and check my question for additional thoughts from folks.

RE: Which is the Hottest Java Web Framework?

The "Break it Down" Blog has a lengthy post on Which is the Hottest Java Web Framework? Or Maybe Not Java? Comparing Java Web Frameworks is hard because so many people are passionate about the framework they know best. Add a couple more like Flex and Ruby on Rails and its downright difficult. Nevertheless, this post is good in that it contains a lot of pretty trend graphs and it looks like the author has done some good research. It's likely the folks that will scream foul are the ones that did poor in the comparison (Tapestry and Stripes, I'm talking about you).

Surprising among the top Java Web Frameworks is the rise of Struts 2:

To quote:

Which is much more interesting I think is how Wicket adoption has stayed almost flat while Struts 2 adoption has spiked. Spring MVC/WebFlow seems to be going no where fast and racing JBoss Seam there.

The popularity of Struts 2 really caught me off guard with it being quite a bit different from Struts 1, I figured it got thrown into the "just another web framework" category, but I guess there is something in a name and it's doing quite well.

Regardless of what you think of the post and trends, you have to appreciate the amount of time the author put into it.

AppFuse Light 1.8.2 Released

AppFuse Light 1.8.2 is a bug fixes release that includes upgrades for Spring, Spring Security, Hibernate, Wicket, Tapestry and many others. In addition, Spring bean definitions were replaced with annotations (@Repository, @Service and @Controller). See the Release Notes for more information on what's changed since the last release.

AppFuse Light now offers 60 possible combinations for download:

• Web Frameworks: JSF (MyFaces), Spring MVC (with Ajax, Acegi Security, JSP, FreeMarker or Velocity), Stripes, Struts 1.x, Struts 2.x, Tapestry, WebWork, Wicket
• Persistence Frameworks: Hibernate, iBATIS, JDO (JPOX), OJB, Spring JDBC

If you have any questions about this release, please subscribe to the AppFuse user mailing list by sending a blank e-mail to users-subscribe@appfuse.dev.java.net. You can also post questions in a forum-like fashion using Nabble: http://appfuse.org/forum/user.

A Positive Wicket Experience

Julian Sinai recently released the first version of his company's product based on Wicket. In A Year of Wicket, he describes the experience (emphasis mine).

I've been working with Wicket for almost a year. We've just released our first product that uses Wicket for the user interface, and so it seems like a good time to take stock. Unfortunately, it's not a public site, it's an installable enterprise product, so I can't show it to you. If you don't want to read further, here's the executive summary: Wicket rocks!

I was hired as the GUI Architect for this project. I came to it with many years of GUI experience, mostly using Swing, but without a lot of web development experience.

Because of my Java and Swing background, I was drawn to Wicket. It maps fairly closely to the Swing model of development. So does GWT, but when I evaluated it, it seemed so different from other J2EE frameworks that I felt it was a step too far. No HTML, and no WAR files, for example. This made my colleagues nervous, who were used to Struts and PHP. Me too, as a matter of fact.

I had done some pretty serious prototyping for another project with Tapestry, and there were certain things I liked, like runtime bytecode generation. But the learning curve was pretty steep. At one point I needed to create a custom component, and to do so I needed to learn about engine services and other arcane things that I felt made the process too hard. By contrast, custom components are Wicket's bread and butter, and they are very easy to build.

I also took a close look at JSF. It seemed overly complex to me, and not much of a departure from the Struts era. It came across as a technology designed by committee, with the combination of several complementary libraries required to get the job done, and there are still too many configuration files.

So we decided to use Wicket.

...

One of Wicket's advantages is the strict separation of design from behavior, that is, HTML from code. While we did not have a web designer on the team who built the HTML (the developers did this), and therefore didn't get any mileage from the separation in that sense, we definitely gained from having all the behavior in Java code, because it gave us all the power of refactoring, compile-time error checking, and maximum reusability. [Read More]

I really like how Julian talks about reasons they didn't choose other frameworks. Beyond that, I think it's important to note that Wicket was a perfect fit for someone with heavy Java and Swing experience. I still think Wicket is a little verbose for Web developers that program in Java (me), but it's unlikely there's very many of those. Building a form in Java seems so much more cumbersome than building it with HTML - but that's probably just me.

Java Web Framework Smackdown at TSSJS in Vegas

This year's TSSJS is starting to look like an excellent conference. I'm particularly excited to be moderating the following Expert Panel.

Java Web Framework Smackdown: Struts 2, Spring MVC, Grails, Seam/JSF and Wicket
The leading advocates of today's popular Web frameworks will duel under the Vegas Lights. Come and learn when to use your favorite framework and to see if it can live up to its hype.

We're talking about productivity, scalability and maintainability of Java-based Web applications. The emerging trend is that simplicity is better and productivity matters. Furthermore, if maintainability is the most costly part of any application -- how do these frameworks perform?

Attend if you're a Java Web developer, or if you simply like good entertainment. A working knowledge of the popular Java Web framework options will make this session more fun. If you haven't worked with any framework, come and learn who has the best spokesman.

I plan on bringing the boxing bell from OSCON 2005 to make this session one of the best in the show. I'll be coming up with a list of questions for these experts in the next couple of months. In the meantime, if you have any suggestions, please let me know.

With a venue like The Venetian, why wouldn't you go?

AppFuse Light 1.8.1 Released: includes upgrades to Spring 2.5 and Wicket 1.3

AppFuse Light 1.8.1 is a bug fixes release that includes an upgrade to Spring 2.5 and Wicket 1.3 RC1. See the Release Notes for more information on what's changed since the last release.

What is AppFuse Light? Click here to find out.

AppFuse Light is a lightweight version of AppFuse. I was inspired to create it while writing Spring Live and looking at the struts-blank and webapp-minimal applications that ship with Struts and Spring, respectively. These "starter" apps were not robust enough for me, and I wanted something like AppFuse, only simpler.

AppFuse Light is designed to show Java Web Developers how to start a bare-bones webapp using a Spring-managed middle-tier backend and Hibernate for persistence. By default, AppFuse Light uses Spring for its MVC framework, but you can change it to JSF/MyFaces, Stripes, Struts 1.x, Struts 2.x, WebWork, Tapestry or Wicket. In addition, there's a number of extras for Spring MVC, including Velocity and FreeMarker versions, Ajax support and Acegi Security support.

This project was formerly named Equinox and has been under development since April 2004.

AppFuse Light now offers 60 possible combinations for download:

• Web Frameworks: JSF (MyFaces), Spring MVC (with Ajax, Acegi Security, JSP, FreeMarker or Velocity), Stripes, Struts 1.x, Struts 2.x, Tapestry, WebWork, Wicket
• Persistence Frameworks: Hibernate, iBATIS, JDO (JPOX), OJB, Spring JDBC

If you have any questions about this release, please subscribe to the AppFuse user mailing list by sending a blank e-mail to users-subscribe@appfuse.dev.java.net. You can also post questions in a forum-like fashion using Nabble: http://appfuse.org/forum/user.

If you're a developer of one of the frameworks that AppFuse Light uses - I'd love a code review to make sure I'm "up to snuff" on how to use your framework. I'm also more than willing to give commit rights if you'd like to improve the implementation of your framework.

Live demos are available at:

• Spring · Spring + Ajax · Spring + Acegi
• MyFaces + Facelets
• Stripes
• Struts 1 · Struts 2
• Tapestry
• WebWork
• Wicket

What's on tap for AppFuse Light 2.0? Here's what I'm hoping to do:

1. Drop the seldom-used persistence frameworks: JDBC, JDO and OJB.
2. Drop Struts 1.x and WebWork as web frameworks (replaced by Struts 2).
3. Support the same persistence frameworks as AppFuse: Hibernate, iBATIS and JPA.
4. Re-use appfuse-service, appfuse-hibernate, appfuse-ibatis and appfuse-jpa in AppFuse Light. I'll likely include the core classes (User, Role) since AppFuse Light is more "raw" than AppFuse.
5. Require Java 5.

Let me know if you disagree with any of these items or would like to see other enhancements.