Kai Wähner (Twitter: @KaiWaehner, Blog: www.kai-waehner.de/blog) is an IT-Consultant in the Java EE, SOA, Cloud Computing and Big Data world. In his real life, he lives in Erlangen, Germany and works for TIBCO (www.tibco.com). Besides solving huge integration problems for large companies, Kai writes articles for magazines and speaks at international IT conferences such as JavaOne. Feel free to contact him via Twitter, LinkedIn or Email. Kai is a DZone MVB and is not an employee of DZone and has posted 51 posts at DZone. You can read more from them at their website. View Full User Profile

Categorization and Comparison of Popular Web Frameworks in the Java / JVM Environment

  • submit to reddit

The following article shows a categorization of Java / JVM web-frameworks, considering different types of web applications. The intention is to give an overview, not to start a flame war.


An uncountable number of web-frameworks exists in the Java environment. If you visit IT conferences or google for web-framework comparisons, almost always you find a discussion about the advantages and disadvantages. Often, a flame war is the consequence, each guy likes or dislikes a specific framework. Thus, a neutral comparison, which helps to choose the one which fits best for your requirements, is rare.

In the following, I try to compare web-frameworks in a more neutral way. I categorize the most important web-frameworks in the Java / JVM environment (i.e. frameworks which generate bytecode for the JVM) by classifying them to different types of web applications.

My experiences from discussions with colleagues and customers showed me, that the consequence is a neutral overview without any flame war or framework-bashing. I wonder if you think so, too...

Types of Web Applications

Different types of web applications exist. They have different sizes. Thus, the time to develop them is varying, too. The following chart shows the types of web applications:

Classical Web Application

A classical web application (e.g. Amazon) is server-centric and uses HTML user interfaces with multi-page structure, bookmarking and forwards / backwards navigation. It is well-known since the beginning of the internet age. In the course of time, AJAX was integrated. Thus, just the changed part of the site has to be refreshed. A plugin is not necessary, but therefore the user inferface must be adjusted explicitly for every web browser.

Rich Internet Application (RIA)

A Rich Internet Application (e.g. Pokerstars) provides a modern looking web application with animations, effects and multimedia features. The web application is hardly recognizable as web application, there is no HTML user interface with forms, drop down boxes or tables. Typical features of web browsers such as bookmarking or forwards / backwards navigation are usually missing. A plugin must be installed required (e.g. Java Runtime Environment or Adobe Flash Player).

Rich Client

The Rich Client mixes the characteristics of classical web applications and RIAs. The web application is client-centric (i.e. the user interface is loaded to client at the start of the application). The view uses HTML widgets, thus no plugin is required. Contrary to RIAs, the goal of a Rich Client is NOT to offer a modern looking user interface, but to improve the usability of an already widespread and accepted view.

CRUD Client

A CRUD Client complies to a classical web application. However, it primarily offers functionalities to create, read, update and delete data.

The web-frameworks for CRUD clients have a conceptual difference: Instead of just realizing the user interface, the whole application (database, application logic and user interface) is realized at once. Important characteristics of these frameworks are „Convention over Configuration“ and „Code-Generation“. The main goal is high productivity, thus often „modern“ JVM languages such as Groovy or Scala are used.


A Portal offers the possibility to present different applications such as standard software, individual components or websites in a consistent way. A Portal Server such as Liferay Portal must be used in combination with one or more web-frameworks. The effort is huge, because you have to use a Portal server, create portlets and implement the communication between different portlets. A Portal does not make sense for a small web application - e.g. if you want to realize just a little CRUD Client, then a Portal Server and Portlets are oversized.

Categorization of Java / JVM Web-Frameworks

The following chart categorizes the most widespread and popular web-frameworks in the Java environment. Some important notes before:

  • Complexity implies the view of a Java developer! Therefore, it is much more complex and time-consuming to learn e.g. Grails because you have to learn Groovy first.
  • JavaFX: The new JavaFX (which will be released 2011 with a Java API) is meant here.
  • Adobe Flex does not compile Java bytecode. Due to missing alternatives for a RIA in 2010 (besides the old JavaFX without Java API, bad IDE support, and so on), it is added nevertheless. Flex can be integrated with JEE by using tools such as GraniteDS.
  • I cannot tell you, why JSF is a little bit above Wicket or Tapestry. The intention is to give an overview and a categorization, no flame war. So you also could put JSF a little bit below Wicket and Tapestry. Does not matter! The same is true for the other frameworks.

Key Message: Right Tool for Right Job!

The key message is: Use the right tool (i.e. web framework) for the right job!

If you want to realize...

... a classical web application, choose JSF or Wicket or Tapestry if you want to use a component-based framework. Use Spring MVC or Struts if you need an action-based (also called request-based) framework.

... a RIA, you have to use Flex or JavaFX, because none of the other frameworks offers the possibility to realize a modern looking application such as Pokerstars at the moment.

... a Rich Client, you have to evaluate if you need a client-centric framework (such as GWT) or a server-centric framework (such as Vaadin or ZK).

... a CRUD Client, you can realize it with every framework. If you want to realize it with high productivity, you should use a framework which is constructed exactly for this. If you are a good Java developer, you can use Spring Roo or the Roma Meta Framework. Grails (using Groovy) or Lift (using Scala) are good alternatives, if you are familiar with a „modern“ JVM language or if you want to learn that language.

... a Portal, you have to do much more work. Choose a Portal Server, use Portlets, and choose your web-framework. For this purpose, JSF could be a good choice in the majority of cases, because good (and standardized) bridge implementations are available. But other web-frameworks offer "integration plugins", too.


I showed you a categorization of web-frameworks in the Java / JVM environment, considering different types of web applications.

I hope this is a good overview. Discussions are welcome, but please do not start a flame war. Do not tell me that JSF is better than Wicket because of XYZ. But of course, tell me if you do not like this categorization considering different types of web applications. Tell me if some important framworks are missing or if anything else is in your mind besides a flame war.


Best regards,

Kai Wähner (Twitter: @KaiWaehner)


[Content from my Blog: Categorization and Comparison of popular Web Frameworks in the Java / JVM Environment - Kai Wähner's IT-Blog

Published at DZone with permission of Kai Wähner, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Andy Leung replied on Fri, 2010/12/31 - 8:50am

A portlet does not make sense for small web applications.
IMHO, I think it's the other way around. Portlets are supposed to be miniature versions of million function of large scale system broken down. Portlets are actually quite simple to develop comparing to CRUD web app. If installing Portal (especially Liferay) is considered extra work, I think it's the same for Tomcat because Liferay or most of the Portal systems are come in a form of installable with configurations after, same as Tomcat.

Portal is a huge resource pool, which provides even better and easier way to leverage resources such as persistence, network, cache, UI and etc. Therefore, coding portlet is fairly simple comparing to regular web app.

Again, this is just my 2 cents, and by the way, I don't work FOR Liferay but I have been using it for 4 years for enterprise development, it's one of the rare quality products that I have seen on the market.

Cheers and Happy New Year!

Kai Wähner replied on Fri, 2010/12/31 - 9:03am in response to: Andy Leung

Hey Andy,

sorry, my mistake. You are right. I meant "Portal", not "Portlet" here. I changed it!


To clarify:

A portlet can be a small web application, of course. But you should not use a Portal if you need just one small web application. But it does not make sense to use a Portal Server and Portlets to realize a small CRUD Client. Use a Portal if you want to integrate several different applications.


Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Andy Leung replied on Fri, 2010/12/31 - 10:01am in response to: Kai Wähner

Thanks, agreed :)

Scott Hickey replied on Fri, 2010/12/31 - 10:55am

re: Grails is complex "because you have to learn Groovy first" Is this based on personal experience using Grails on a project? My *experience* , based on three paid Grails projects, is that the complexity of Groovy is a non-issue for experienced Java programmers. Just as importantly, learning Groovy + Grails was easier for less experienced Java programmers that using Java + Struts or even Java + Spring MVC, which I find amazing that you place at the same complexity level as JSF. My experience may be biased in that I place a high importantance on reducing the complexity of testing. If it is hard, most programmers won't do it. I'm not sure testing could be much easier than it is with Spring 3 or Grails.

Kai Wähner replied on Fri, 2010/12/31 - 11:35am in response to: Scott Hickey

Hey Scott,

yes, that is my personal experience. I used Grails in a (small) project. It was complex (i.e. time-consuming) for me to learn Groovy and Grails compared to JSF stuff (such as the JSF life cycle and JSP / Facelets) or the Component Model of Wicket.

In fact, you have to learn Groovy concepts (such as Basic Groovy Syntax, Closures, Builders, and so on) in addition to the web-framework stuff (such as GSPs). Personally it took me longer to get started with Grails than with other (Java) web-frameworks.

Considering the complexity of testing you probably are right. If you want to test with JSF, you have to use e.g. JSFUnit. Testing with Grails is much more fun :-)


Best regards,

Kai Wähner (Twitter: @KaiWaehner)


Philip Andrew replied on Sun, 2011/01/02 - 2:37am

Hi, I made SlimStack which helps make Liftweb easy to understand and to get started with http://www.getslimstack.net/

Cristian Chiovari replied on Sun, 2011/01/02 - 4:00pm

I think for the Crud + Portal thing you should take a look on OpenXava. It deserves to be in your matrix. Conclusion to you article : one of the best short comparisons !!!

julien gaucher replied on Sun, 2011/01/02 - 6:13pm

some random comments :

jsf is way more complex than struts2 or springMVC.

i think that one matrix that could be interesting is java centric or web techno centric.

  • jsf/gwt are java centric : cool if your team don't know well html/js/css but hell if you want to work with jquery plugins and a web designer team
  • wicket is intermediary
  • spring mvc/struts2 needs a view technologie that need a good understanding of html/css/js

you should add play framework which is a sort of grail in java and offer some interesting features (hot recompile, no crappy servlet api etc...

Kai Wähner replied on Mon, 2011/01/03 - 2:06am

@Christian: Never heard of OpenXava. I will try it out!

Nevertheless I think, most people will use Spring Roo for creating CRUD Clients in the future. It will probably be the most widely-used one because of a large community, many publications (books, blogs, tutorials, talks at IT conferences) and a powerful vendor.

@Julien: I do not think that JSF 2.0 is more complex than Struts or Spring MVC. That is just true for JSF 1.x.

I know the play framework - I saw it at a Java User Group session. It is interesting, too. But same problem as with OpenXava and Roma Meta Framework: Good, easy to use frameworks - BUT too little community and publications compared to Spring Roo :-(

Tabea Steiner replied on Wed, 2011/04/13 - 3:42am

Hello Kai, due to some research for my bachelorthesis I've been gratefully reading your articles about categorization and comparison of webframeworks, here, as well as in the Javamagazin (1.2011). As far as my (extremely slight) experience goes I was part of a team developing portlets in Liferay using JSF. In your article you stated there were other web-frameworks which offer "integration plugins". During my research I only came across using JSF for developing portlets.. Do you know if there is some kind of overview comparing the use of web-frameworks for developing portlets or could you suggest information for further reading? I really appreciate your articles, you're doing a great job. Thanks

Kai Wähner replied on Wed, 2011/04/13 - 8:19am in response to: Tabea Steiner

Hey Tabea,

great to hear from you. I hope you also read Javamagazin 2.2011 with the second part of the article :-)

I am not aware of a comparison about portlet-support of web-frameworks anywhere. You have to google for every framework by yourself and look for its support for portlets.

One more hint: Look at OpenXava, this (very unknown) CRUD framework supports portlet creation out of the box.


Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Kookee Gacho replied on Tue, 2012/05/29 - 12:41am

Many programmers find it useful to keep a copy at their desk so they can look at the code examples and such while they work.-Arthur van der Vant

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.