Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

The Curious Coder’s Java Web Frameworks Comparison: Spring MVC, Grails, Vaadin, GWT, Wicket, Play, Struts and JSF

Introduction: Let get curious…

Web Frameworks are all very different and have been typically created for different reasons and to achieve different goals. Which Java Web Framework will you use in your next project and why would you chose one over the other? There are many features which may sway your decision and of course it will depend on the type of app you’re building.

Why do we need Web Frameworks?

Well, coding good-looking web applications in Java isn’t super easy. In fact, let’s just say it sucks. It can be hard to do and mostly doesn’t give us the rich front-end we strive to deliver to happy users. This is really the catalyst which has caused Web Frameworks to be created. Both, functional and non-functional web app requirements have led to the need for various web frameworks to be created, but this brings us to the opposite problem…there are so many choices out there to use, which web framework should you pick for your next web app?

We thought it made sense to follow up on the Java Web Frameworks section of our popular Developer Productivity Report and see what we had in there back in 2012. According to over 1800 developer responses, here’s what we found:

Web-frameworks-developer-productivity-report

More than just looking at market share and usage in place, we wanted to extend this report on Java Web Frameworks to look deeper at these eight libraries, and find out about what is really important to developers, in addition to looking into how different frameworks make sense for different use cases.

This report is the first of two and will focus on a feature comparison across the following categories:

  1. Rapid application prototyping
  2. Framework Complexity
  3. Ease of Use
  4. Documentation & Community
  5. Framework Ecosystem
  6. Throughput/Scalability
  7. Code Maintenance/Updates
  8. UX, Look and feel

We’re going to compare and contrast each Web Framework in this report against each category above scoring and placing each of them based on our findings. The Java Web Frameworks (and versions) we will be discussing in this report are:

  • Spring MVC 3.2.3
  • Grails 2.2.2
  • Vaadin v7.1.1
  • GWT 2.5.0
  • Wicket 6.8
  • Play 2.1.2
  • Struts 2.3.15.1
  • JSF 2.2

Wait–there is a Part II coming?

In order to avoid a 9000-page report, we wanted to separate it into two parts. In this part, we look at each framework objectively and compare them. In the second report we will take a look at different application types and styles (i.e. use cases), matching the most appropriate Java Web Frameworks to each, from the information and scores from this report. Each application type will care about the categories mentioned in this report to varying extents, which will aid us in weighting each of the categories for the application types. So save some popcorn, keep an eye out for the trailers and make sure you come back for the sequel to this blockbuster report.

What if you no longer had to redeploy your Java code to see changes? The choice is yours. In just a few clicks you can Say Goodbye to Java Redeploys forever.

Continue this on the couch and download the PDF version

  • AlfredoZuloaga

    Excellent article, But I´m not too convinced that Play was best on Throughput/Scalability because others frames can deploy on very strong Java EE Containers like GlassFish, JBoss,WebLogic, Wensphere,etc that are proven excellent on Throughput/Scalability.

  • Claudiu Ion

    don’ forget resin container

    the guys from here http://www.techempower.com/benchmarks/#section=data-r6&hw=i7&test=db

  • Andrea Del Bene

    Don’t want to be self-referential, but the documentation for Wicket has been really improved and updated recently :) :)

    http://code.google.com/p/wicket-guide

  • Christian

    To master Play’s Scala based template engine is not a harder than learning every other template engine. Actually you don’t have to know Scala at all.

    You’ve counted Scala as a disadvantage several times in your comparison, but I think it is a really powerful and clean language, once you’ve mastered it. You can do so much more with so much less code compared to Java.

    Scala is not a disadvantage, Scala is a big win.

  • J.

    This is the most useless Java web framework comparison I have ever red. Too generic, too subjective and biased. Nothing was said, document is full of generic boilerplate parts crowned by dusty score valuation.

  • arhan

    IMO that’s a subjective assessment. Since we used Play2 for our own projects, the developers acknowledge that scala templates certainly helped in many cases, however with its own quirks.

  • Adam Koblentz

    I’d say that requiring Scala knowledge in a Java framework is a disadvantage. If we were discussing a PHP framework that required Ruby, I do not believe anyone would disagree.

  • Simon Maple

    Sorry to hear you disagree so strongly. As our Rebel Labs team is mostly comprised of humans, the text will always be subjective and opinionated and I believe it makes for the most interesting and valuable of articles and reading. If you would like more in-depth information, we have posted more in-depth blog posts on most of the frameworks we discussed in the report on the Rebel Labs blog. The report is already 50 pages, or so, in size which many think is already very long. I suspect we wont see eye to eye on this one, but it’s not always right trying to please everybody :)

  • Han Zhang

    But for building a large app, code maintainability outweighs many other factors, no? So even Struts sits at the bottom of your list by scores, in reality, when building an app with a large number of fine grained features, limited developer resources, large number of users, which one do I pick? Struts. :)

  • Simon Maple

    Hey Han, Very good points. These are actually all planned for our second part of the report. These are merely the category scores. The second report will examine real world app types and weight the categories based on their requirements. This will then allow us to provide recommendations on an app type basis.

  • UmeshAwasthi

    Though overall it is really a good article, but it lacks many aspects.For e.g at some point Author is talking Struts as legacy framework while there is already a new version of Struts derived from WW named as Struts2 while struts has already been declared close for development.

    For UI, i believe both STruts2 and Spring-MVC provides a lot of flexibility of use any view technology or use build in support .Struts2 already providing beautiful Jquery plugin which provides many Jquery powered widgets out of the box while author is talking about Ajax support which was based on deprecated DOJO plugin.

    I believe there are many real time factors which was not considered while doing this comparaion.

  • cblin

    This is no easy task to compare java web frameworks so this article deserves consideration as it does a good job to summarize some of them.

    But I clearly agree with the conclusion : you are comparing oranges with apples.

    Also, I miss some “real world” metric : maintanability, going mobile, going services oriented (i.e lots of small apps working together), testability

    I’ll wait the second part to tell you my full opinion ;)

  • Marc Sch

    I agree, it’s way too generic. A more interesting comparison would involve building an advanced prototype and then looking at things such as performance, caching, lines of code etc.

  • Han Zhang

    Simon’s talking about Struts 2.3.15.1.

  • Yannick Majoros

    Agreeing with some others here: I think there is too much bias in this article. Giving points is bound to be a problem.

    Something that isn’t addressed is the fact that most those frameworks are not part of any spec. I know it’s boring, but I’m convinced it *is* important for the long-term minded professional.

    Been using Struts and Vaadin in professional contexts. You always end up spending lot of time on implementation details, that are not part of any specification. Any problem with component X or feature Y? That’s how it’s implemented, you have to live with it. Maybe it will change in a new version (and break things).

    In contrast, JSF has multiple implementations and is well-specified. Any problem with component Z? Check the spec, you have some reference to have the bug corrected. Plus, nowadays, it’s equivalent in functionality. I don’t even get why I would think at using something else, that would roughly do the same, but without the standardization. That also makes big difference regarding documentation, e.g. the Book of Vaadin might look like a full documentation, but it just can’t compare to a full specification.

    Another thing that I always look at when using someone else code is typing. Vaadin, for example, is full of Object parameters, casting, string parameters, … Those things will break at runtime. JSF has still to evolve in this, but at least you can get your java code mostly type-safe.

    After years of having to deal with them, my general idea of those non java-ee frameworks is that they are the work of some uncontrolled volunteers, some of them creative but not led by engineers. The demo looks nice, but it requires a lot of knowledge of the framework only implementation.

    In contrast, I like the fact that Java EE (5, 6, 7…) is a powerful, well-engineered ecosystem that’s been maintained with a vision.

  • arhan

    Very good comment! But could you elaborate about bias? Bias towards what? Rebel Labs doesn’t relate to any of those frameworks business-wise, and the marks are given by individual devs – of course those marks are subjective. I would say that given the set of categories in which these frameworks are given the standings are pretty fair.

    Well, I wouldn’t give GWT that many points for UI, but yet again – that’s my subjective assessment.

  • henk53

    This is a nice review really, but difficult as well. You either have to be an absolute beginner in all frameworks and then test which one you get productive with first, or you have to be an expert in all of them.

    In the weeks before this report there were individual reviews of most web frameworks, but not for JSF. Did I miss something, or did you guys forgot to post it?

    Although I generally agree with the JSF scoring, I do have a few remarks about the text.

    >prototype applications require just as much configuration as a full application

    Simple prototype applications in JSF require no configuration at all. See for example this one: http://jdevelopment.nl/minimal-3tier-java-ee-app-xml-config

    There is no required web.xml, no faces-config.xml or anything else. When deploying to a simple lightweight Web Profile server (e.g. TomEE) there’s not even any jar to download and put into web-inf/lib or any extra dependency to be put in a pom.xml. As the article shows, zip those files up in a war and copy it to an app dir of TomEE, GlassFish, etc.

    I’m not sure how much simpler things can become, especially for prototyping.

    >JSF are the wizards available in most IDEs that generate most of the boilerplate code and configuration for you.

    I’m really curious here; what boilerplate code and what configuration would that exactly be? (honest question) Is there any such configuration or boilerplate in the article I referenced that such wizard would generate?

    IDEs work great with JSF for auto-completion of tags, auto importing of namespaces, and to auto-complete and navigate into EL expressions, but I haven’t seen much JSF developers really using any wizards to generate configuration, since when beginning there’s simply isn’t any that’s needed.

    The complexity review is the only section in the report when I really disagree with the points raised. The text just doesn’t feel coherent.

    >JSF is incredibly complex, and that is the largest downfall of the framework. However, this is not JSF’s fault, this is due to the Java EE specification and the inflexibility of runtimes available.

    So JSF is complex because of the Java EE specification? What’s in Java EE that makes JSF complex to use then? Why are the runtimes inflexible? Inflexible with respect to what?

    >There are open source implementations of the JSF specification that do allow the use of non-Java EE containers like Tomcat

    This sounds a bit weird…

    There are ONLY open source implementations of the JSF specification, namely Mojarra and MyFaces. They both indeed run on Tomcat (and even on Jetty). The sentence seems to suggest that the “normal” JSF implementations are closed source, but if you look closely and know where to look, there really also are open source ones. This couldn’t be further from the truth really.

    >which cuts down tremendously on the complexity of having to run a full Java Enterprise application server

    I just don’t get this… I really don’t. What complexity of having to run a full Java EE application server? TomEE is a 25MB archive. You download it, unzip it, and start it. It’s exactly the same as you do with Tomcat! The same goes for JBoss, GlassFish, Resin… it’s every time just a download, unzip, run. Nothing more. Every modern container starts up in a few seconds (JBoss EAP 6.1 on my system is 1.5 seconds, TomEE is 2.something…).

    You guys at zeroturnaround did the application server report, so I guess you really should know this.

    In fact, as mentioned above, running the simple JSF app I referenced earlier is much less complex on any of the modern application servers than on Tomcat. With JBoss, GlassFish, Resin, Geronimo, Liberty, JOnAS, … it’s download, unzip, start, deploy those 3 source files. With Tomcat it’s download, unzip, start, look for JSF website, hunt jars, find right version, download, copy jar to web-inf/lib, deploy 4 (or 5) files. It’s not a super big deal of course, but it’s 2 extra steps compared to a Java EE server.

    > JSF is very easy to get up and running and often does not require extra downloads or configuration as the necessary code is bundled in any Java EE compliant application server.

    Is this a different person writing? It seems to contradict the earlier text. Though I naturally agree with this, it left me a bit confused here.

    >Assuming it’s not enabled already, getting JSF support in your application server can be as simple as enabling a checkbox.

    Isn’t Liberty the only server that requires this “checkbox” (an entry in server.xml)? I don’t think I’ve ever seen any other server requiring this, but I’m eager to learn what other one also wants this (if any).

    >Java EE can be overwhelming and incredibly useful features can seem obtuse or obfuscated by poor documentation or easy to miss in the corpus that is the body of Java EE features

    I agree with this point, Java EE needs to have more documentation that represents Java EE as the framework itself, not as a collection of the alphabet soup JSF, CDI, JPA, etc. For instance using CDI backing beans in JSF, with EL 3.0 expressions and Bean Validation constraints is really well integrated. You really wouldn’t tell most of the times you’re dealing with 4 separate specs. Yet indeed, core documentation often has to be looked up at 4 places.

    > Oracle has a large part in determining and supporting features present in the specification.

    This is technically true. Oracle is leading the JSF specification and has the ultimate say. Technically…

    In practice however the spec lead (Ed Burns) runs JSF in the most open source way possible. JSF was the first specification of Sun that had an open source implementation, the first one that had a fully public JIRA for community issues and where things were discussed openly on a public mailing list.

    If you follow the mailing list discussions a bit then it becomes clear how much the Mojarra developers ask for opinions and agreement of the non-Mojarra and non-Oracle people all the time. If you look at the features that made it into JSF 2.2 (see http://jdevelopment.nl/jsf-22) then you can see that many of them were community submitted ideas and many others were chosen based on community voting. At the start of JSF 2.2 I remember Ed Burns asking everyone to vote for their most wanted features in JSF 2.2.

    > There is still a community based on JSF and there are a few exciting alternative technologies built on JSF, namely the MyFaces, PrimeFaces, and IceFaces.

    This is perhaps not 100% correct. MyFaces is not an alternative technology build on JSF, MyFaces *IS* JSF. As mentioned above, it’s one of the implementations of the JSF spec (Mojarra being the other).

    PrimeFaces and IceFaces (please don’t forget RichFaces here ;)) are not really “alternative technologies”. They are component libraries. One of the major goals of JSF was to enable to existence of such collections of components (widgets, controls). They are not competitors to core JSF, nor do they specifically fix flaws in JSF that Sun or Oracle forgot about. The fact that they exist means that JSF succeeded with one of its goals; to enable a rich ecosystem of available third party components.

    >JSF’s ecosystem includes component libraries such as Richfaces, OmniFaces, Primefaces, IceFaces, ADF Faces as well as the extension points, including PrettyFaces, GMaps4JSF and Mashups4JSF.

    Nice enumeration here :) One tiny correction; though OmniFaces definitely has its share of components, it’s generally considered to be a utility library (like Guave for Java SE) and not in the same space as RichFaces, PrimeFaces and IceFaces. A bit of a larger correction is that ADF Faces is a bit of a different thing. There’s a regular component library called Trinidad that is derived from ADF Faces, but ADF itself is difficult to explain. It is a complete higher level framework where the UI part is kinda like a fork of JSF with many things added, but typically lagging behind the latest “normal” JSF. Better not touch this subject in a casual JSF review ;)

    > JSF can be easily added to your existing Java EE environments and immediately receives all of the benefits inherent in the Java EE ecosystem. JSF can be leveraged on non-EE containers as well, with open source support from the Apache Foundation with their MyFaces implementation of the JSF specification.

    This again sounds like “the other person” wrote it again. Good text and almost seems to contradict the earlier statements again. Just wanted to note here again that the Oracle implementation is also fully open source and also runs on non-EE containers.

    >JSF applications can be performant, but really the performance gains come from clustering Java EE application servers.

    It also performs quite well without any clustering involved, see this article: http://content.jsfcentral.com/c/journal/view_article_content?cmd=view&groupId=35702&articleId=73398&version=1.8#.UfriNZV3qmQ

    I like that you mention @Asynchronous can be a performance boost as well :) I don’t see this often being mentioned in (JSF) reviews!

    >One of the stated goals of JSF is to help developers produce better code, but we do not see how they facilitate that.

    I think the way Facelets templates works, with the template clients and such, and the way components are bound to backing beans via the concept of bi-directional EL expressions really helps to produce better code. It’s really an easy way to cleanly separate UI layout and backing data.

    Okay, the few remarks got a bit longer than originally anticipated, but I hope it’s useful ;)

  • UmeshAwasthi

    Than saying that Struts is legacy framework is totally wrong assumption

  • Santosh Maskar

    I think you forgot mention the stripes (http://www.stripesframework.org/display/stripes/Home) which has gained popularity in terms of use from last 5 years.

  • arhan

    Stripes is nice and we even support it in JRebel. But the report would not fit all the frameworks – there are 100500 of them in the wild :)

  • Yannick Majoros

    +10!

  • Yannick Majoros

    Ok let’s not expand about bias (just my feeling) and say I just don’t think the review is objective. @henk53:disqus commented in details about jsf, exposing some random assertions which simply aren’t true. Same lack of objectivity for Vaadin, in my opinion: just asserting it’s quite easy to use with nice results out-of-the-box and giving it high scores without too much debate. Not my experience, I think this specific one is a real mess ;-)

  • arhan

    Fair enough. How about you take same categories and try rating ‘em yourself, and then let’s compare, how will the results differ? That would be quite an interesting test.

  • Yannick Majoros

    Lacking time, but why not if it’s not urgent. I could do some of the frameworks, not all of them. Still wondering if grades are relevant, though.

  • arhan

    Just pick a few. I’m planning to do that myself also, just to see how my personal preferences match the results from the team.

  • Han Zhang

    Out of the ones in this comparison, I like Struts2 the most.

    It strikes a very fine balance between function granularity and abstraction. Most of the dish-washing type of work are packaged away into fine grained APIs, which live on its very flexible interceptor-based architecture. With OGNL and xwork’s validation, it takes away much of the tedious data conversion and validation type of work. The user data live in same object structure from JSP all the way to the database.

    It does have a learning curve looks like the shape of the square root. Once you reach the plateau part, you are extremely productive. The more I use Struts2, the more I appreciate what it offers. It’s the #1 MVC framework I will choose to use any day for non-trivial app with extremely limited developer resources and large user base requirements. I see its life in the next 10 years, definitely not a legacy framework at all.

  • UmeshAwasthi

    I was also wondering about author perspective. I am working with struts2 and Spring-MVC from quite a long time and i always prefer Struts2 due to flexibility and option to add my custom plugin as well interceptors stack

  • Han Zhang

    Yep, agree struts2′s open and flexible core architecture is its most liked feature. Value stack, OGNL, validation, and xwork (command pattern) are my favorite features, among others.

  • Jevgeni Martjushev

    We didn’t explicitly call Struts a legacy framework, but rather said that “Many devs see Struts as a legacy technology”.

  • Dani Pardo

    After reading the article I cannot but feel quite sad: It’s just the amount of bloat, and the obsession for reaching architectural perfection that has lead us to frameworks so complex. Maybe we should get back to the basics, using plain servlets and jsp :)

  • gregorsam

    Where is zk?

    I think for the ease of use it is the best. Practically no XML required if you want to code everything just in Java. Rich set of components.

    In my view that is a significant omission.

  • Luc Bourlier

    There an error in the result table on the last page. Play is the ‘winner’ in the Throughput/ Scalability category with a 5, but the scores of Vaadin and GWT with 4.5 are highlighted in blue.

  • arhan

    As you can see the report features only a few frameworks. It would have been an enormously log PDF if every framework was included.

  • arhan

    I advocate for NoFramework movement! Perhaps, one day, I will create a framework and call it “NoFramework” :)

  • Simon Maple

    Thanks for the feedback, we’ll update when we refresh

  • Simon Maple

    Is nobody going to comment about how cringe our trailer videos are? We’ll make them worse and worse if you don’t stand up and say something!

  • iNikem

    How it is possible to evaluate performance characteristics without real load testing and measuring? “Will my application perform will in production if it gets hit by Slashdot effect?” “You use Hibernate and Spring? Then surely it will! They are giants!”

  • omid pourhadi

    where is the Jboss Seam ?

  • M

    Thanks for your hard work of making such challenge report.

    I am in the process to evaluate and choose web framework for my next project. This is why I read this article from beginning to end. However, I found the info from this article is not useful as I expected.

    My question is – how come the most popular web framework just get the second to bottom score in your ranking system recommended?! Your ranking system is not totally-unreasonable, but I have to say it is not as useful as it should be, since it is not helpful to us to understanding the fact. Either some of ranking values used are not accurate, or some more important factors missing over there.

    Anyway I think your survey result is the most valuable point in this report, since it shows the kind of result comes from the group intelligence of the java community. Thanks again.

    Cheers
    M

  • Sudheer Avula

    A very good write up on comparing web frameworks in different aspects….

    This is a very good source of information to conquer the maze of web frameworks. I could at least filter some of the frameworks based on the score.

    Kudos