Kai WaehnerCategorization of Web-Frameworks in the Java Environment
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.
Motivation
An uncountable number of web-frameworks exists in the Java environment. If you visit IT conferences or google for 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.
Portal
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 a good choice in the majority of cases, because good (and standardized) bridge implementations are available. But other web-frameworks offer “integration plugins”, too.
Conclusion
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)
10 comments
It’s an interesting way of categorizing. It makes sense mostly. Just for the sake of having a discussion, the main things I’d personally disagree with would be:
1) the placement of Lift on the horizontal axis: I’d move it to the right (RIA) to be at least equivalent to Wicket/ JSF
2) the placement of Flex on the vertical axis: While it is true it’s another language and (if you’re not yet using say Eclipse and want to go for Flashbuilder – which I would recommend) another IDE, the environment really isn’t all that complicated. I would certainly place it as less complicated than learning Lift (if you’re new to Scala).
3) while GWT runs in the browser and hence you could view it as very suitable for RIA, I don’t think it scales that well for complexity as e.g. Wicket does. Following their proposed patterns (and for grieves sake, I’d stay away from the extensions like SmartGWT or GXT as that makes the whole model much more inconsistent, and gawd knows how many engineering hours we lost trying to track down GXT issues not to mention it is impossible for us to upgrade to the next version of GWT now) keeps things neat, but the amount of code needed to do complex component interactions is easily three times compared to that needed with Wicket. In my experience at least. Mostly because you don’t have the regular request/ response cycle and have to do everything asynchronous, with events and listeners etc.
4) with a good portal server, and provided you can live with the limitations of the portal standards, I think it’s actually pretty straightforward to develop portals. To be fair, I haven’t done that a for non-trivial apps.
Cheers,
Eelco 🙂
@Eelco
to 1) I agree! You could move the CRUD frameworks a little bit to the right.
to 2) Well, maybe Flex is a little bit easier to learn, you might be right.
[I updated the chart due to these notes]
to 3) It is true: Because you use another programming model, you have to write more classes for events, listeners, and so on. Thus, it is more boilerplate code – but I do not think that the complexity is higher because of this.
to 4) Well, in theory writing Portlets is easy. But besides additional effort for writing the portlets and the communication between different portlets, several further pitfalls must be avoided. (I also do not have extensive experience with Portals and merely learned this in a workshop at a conference.)
A couple of comments. I agree with Eelco regarding GWT. Try this: use Spring Roo to generate the simplest possible GWT CRUP app (say just one domain entity) and see how many GWT-related classes and boiler-plate code you end up with. Still think it is less-complex?
I’m surprised to see Grails rated as more complex actually, but I understand your rationale that Groovy is a new language to learn. But then I think you are forgetting the fact that JSP, JSP-EL, JSF-EF, ZK-EL are all new languages to learn. Right? For example, if you choose a simple request-oriented framework like Struts or Spring MVC, you will have to mess around with JavaScript just to add Ajax for example. In my experience, this is what you will end up with for a real-life app:
http://ptrthomas.files.wordpress.com/2008/05/why_wicket.png
Lastly I sincerely think the term RIA is misleading and misused a lot nowadays. Today, with HTML5 you can match what used to be considered only possible using Flash / Flex. Remember the time Google had a playable Pac-Man game in place of their logo once.
Hey Peter,
thank you for your comments.
I agree: The generated GWT application of Spring Roo has too much boilerplate code. Many classes are created for every entity. Also, the MVP pattern (integrated in GWT 2.1) enforces several different classes for the separation and increases the complexity for getting started a lot! But in my opinion, a Spring Roo generated application is no good example for a GWT application 🙂
I disagree: In my opinion it is much more effort to learn Grails compared to JSF or other “Java frameworks”. 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.
I agree: HTML 5 is awesome. You can create a lot of “RIA stuff” with it where Flash / Flex was necessary in the past. But: HTML 5 is not finally standardized and production-ready in web browsers yet. Moreover, realizing web applications with HTML (or ASP.NET or plain JavaScript frameworks such as jQuery) is not considered in this comparison of “Java / JVM web frameworks”).
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Hallo Kai,
ich wollte anmerken, dass diese Arbeit auf Basis einer Studie deines vorherigen Arbeitgebers essendi it GmbH fußt. Inzwischen arbeiten wir an weiteren Studien zu interessanten Themen.
Viele Grüße
Thomas
Hallo Thomas,
freut mich mal wieder von dir zu hören. Und richtig, den Einstieg in das Thema habe ich in einigen sehr spannenden Monaten bei essendi it geschafft. Dort haben wir diverse Web-Frameworks analysiert.
Ich bin schon auf die Ergebnisse der eurer geplanten BPMN-Studie gespannt…
Gruss Kai
I wonder where the Play Framework sits from your point of view. Also curious which web frameworks you are currently/recently using. Do you know Groovy and/or Scala?
Hey Steven,
I know Groovy and Scala. I assume you ask due to the categorization (high complexity of Grails and Lift)? Remember: The diagram is from the view of a Java developer. Therefore, it is much more effort for a Java developer to use Grails or Lift because you also have to learn the new language.
I like both Groovy and Scala. In our projects, we are using mostly GWT, JSF and Rails (Ruby). Personally, I really like Grails and would prefer it to Rails due to its better JVM integration. Actually, we do not use Groovy or Scala for web applications in projects yet (unfortunately). I do not like Lift for several reasons.
Play is also a nice framework. Especially, I like Play 2.0 and its cool Scala integration. I think Play is a very lightweight framework and good for small to medium classical web applications. Here, it could be used instead of JSF. Though, for large classical web applications I would prefer JSF. I would not use Play for Rich Clients / RIAs, because I do not like to much JavaScript and Template hacking. I would prefer GWT or JavaFX.
Thanks for the response Kai. I’m not too fond of Lift either even thought it’s pretty good in some areas (like Comet). I’m liking the look of Play 2.0. I often look over the wall at Grails and Rails but I’m not as fond of dynamically typed languages as I once was. I kinda hope that the JavaScript tools get much better so that for some “corporate” projects, we don’t have to compromise by choosing JSF.