Red Hat

The web framework space is a-changin'

Posted by    |       |    Tagged as

Matt Raible lists his picks of the top web frameworks for deploying on the JVM:

  • GWT-Ext
  • Wicket
  • Grails
  • Flex/OpenLaszlo
  • Seam
  • Struts 2

What I think is most interesting about this list is simply how /different/ each of these frameworks is from each other. A couple of years ago, any list of the top web frameworks would have featured a bunch of metoo-ish action-style-MVC frameworks, with maybe one or two component-style-MVC frameworks thrown in. I /could/ summarize this list by saying that the balance seems to be shifting in favor of component-oriented approaches, but I don't actually think that this is the real story here.

You see, the component frameworks listed actually have much more that is /different/ about them than they have in common. And the same is true of the two action-style frameworks.

So the real story is that there has been a whole lot of creative thinking going on in the web framework space in the last couple of years (if I recall correct, four of these six frameworks did not even exist three years ago).

For the record, I believe that /any/ of these frameworks is a good foundation for web development, and a big improvement upon what people were using a few years ago.

Now, what I'm really interested to see is what happens next. Will certain projects (for example, Seam and Grails) decide to focus their energies on problems like orchestration, state management, data access and integration, while supporting /multiple view technologies/, and leaving other projects (for example, Wicket, JSF, GWT and Flex) to focus their energy upon the view? Or will each of these projects need to grow independently into a full stack solution?

Clearly, the example of Rails shows that a single project can deliver a full stack solution and that this is attractive to many users. However, it's not clear to me that this approach is as natural in the Java world, where we are more comfortable with choice and with heterogeneous technology environments, and where we are somewhat less inclined toward hero-worship.

The strategy we want to follow with Seam is to support multiple view technologies. We don't yet have a definitive list, but the ones I'm thinking of are JSF, GWT, Flex and potentially Wicket. But we're not kidding ourselves that this is a simple task. Developing and maintaining the level of /deep integration/ that Seam has for JSF is extremely expensive.

back to top