The latest expert opinions, articles, and guides for the Java professional.

The 2014 Decision Maker’s Guide to Java Web Frameworks

Introduction: Let’s get even more curious

In the Curious Coders Java Web Frameworks Comparison we looked individually at the top 8 most popular Java Web Frameworks at a feature-by-feature level and scored them. We got some great feedback and added two more feature categories based on this commentary, plus analyzed the strengths and weaknesses of each framework against seven different application types (use cases)…

Download the pdf

What did we see in the first report report?

At the end of the first report we compiled the scores for each framework across all the features we looked at for the comparison. While this is interesting to look at, it does not make any suggestions as to which framework would be good to implement based on different end-user needs, as we haven’t introduced the real world problems/projects into the picture yet.

That’s where this report comes in: here we focus on the application and test use cases with varying application types to determine which frameworks are best suited for that app. Each application type will have different needs, requirements and functional priorities, so the feature areas we looked at in the first report and the two additional parts in this report will be scaled differently. This means we can suggest which framework(s) would be more appropriate than others for different types of applications.

Both reports are follow ups on the Java Web Frameworks section of our popular Developer Productivity Report . Here you can see which were the popular frameworks back in 2012. According to over 1800 developer responses, here’s what we found:

Java Web Frameworks Part 2 popular frameworks 2012

So what are the application types we care about in this report, you ask? We wanted to pick a selection of real-world application scenarios to gauge each framework’s effectiveness, so here they are:

  • CRUD (Create, Read, Update, Delete) app – e.g. Evernote
  • eCommerce app – e.g. Amazon
  • Video/streaming app – e.g. Netflix
  • Desktop application port – e.g. Salesforce
  • Mobile app – e.g.
  • Multi-user app – e.g. Scribblar or Crocodoc
  • Prototyping app – e.g. your own app in development :-)

Once these application types have been weighed, we can then suggest/recommend a web framework based on its strengths, and report which we’d consider using on a similar project if we were to take it on from scratch. The Java Web Frameworks we will discuss will be the same as those looked at in our first report, as follows:

Java Web Frameworks part 2

Download the pdf

Responses (39)

  1. Avatar  

    Simon Maple

    November 5, 2013 @ 3:07 pm

    Hmmm, that Sven guy, in the video clip, has disguised himself well, but I can just about tell that he’s the award winning singing sensation from “Install it Maybe”!

  2. Avatar  

    Oliver White

    November 5, 2013 @ 3:14 pm

    It’s true! I’ve spotted him!

  3. Avatar  


    November 6, 2013 @ 10:53 am

    ZK still not listed. Unbelievable. Is it because of the partnership between Vaadin and JRebel?

  4. Avatar  


    November 6, 2013 @ 12:31 pm

    GWT is insecure because the client is JavaScript!? It is the client technology. Are the other frameworks using something other than HTML and JavaScript?

  5. Avatar  


    November 6, 2013 @ 12:34 pm

    Exactly what I thought. This article should be labeled “The personal preference of someone at JRebel, that company that annoys you with a hundred and one phone calls”!!!

  6. Avatar  


    November 6, 2013 @ 12:36 pm

    I can see that frameworks like Wicket can be more secure because the client just gets opaque references to server side objects but that is at a big cost.

  7. Avatar  


    November 6, 2013 @ 12:48 pm

    As we mentioned before, it is not possible to cover all the frameworks in one go. ZK was never at the top in the survey results anyway.

    You could ask the same about any other framework that you probably like, and the answer would be the same.

  8. Avatar  


    November 6, 2013 @ 12:55 pm

    +1 as well.
    Apparently Vaadin (based on GWT) is more secure because it supports using “security constraints in the deployment descriptor”? WTH!? This has nothing to do with the (front end) framework.

  9. Avatar  


    November 6, 2013 @ 12:58 pm

    Vaadin might have very good security because I believe it has an architecture like Wicket (don’t get me started on the downsides of that). Spring MVC, by default, lets you poke through at any part of the bean. GWT RequestFactory makes you declare things via interfaces. After that you can use Spring security with either.

  10. Avatar  

    David Nouls

    November 6, 2013 @ 1:35 pm

    Is it a coincidence that you seem to favor frameworks that runs mostly on the server side, while JRebel is all about testing server side things ? My experience with GWT is that it is very easy to secure since you remove a lot of server calls. Every server call is subject to attacks. You end up with a thin RPC layer that needs to be secured, for which you can even use Spring security if you wish. But lot’s of cheaper options exists.

  11. Avatar  


    November 6, 2013 @ 2:16 pm

    GWT is insecure bcoz its JS!!. .. very silly argument!!
    thanks for leaving it alone..

  12. Avatar  


    November 7, 2013 @ 4:00 pm

    Those are all old-style Java web dev frameworks. The contemporary style od developing web apps is to build a set of services – where Spring MVC is still of interest – and build a client solely with Javascript, which is served as static content. You may have done your stats on legacy apps.

    Java services plus JS client Is fast, simple (if done right), secure (because you check security at the service level, where you decide what resources to provide access to for various roles, instead of deciding what operations to allow, if you build a RESTful API for your app), provides a service layer available to 3rd parties for free and a lot better (both unit and integration) testable than more traditional approaches.,It significantly cuts boilerplate code and moves a lot of logic and computational effort away from the server.

    Cutting boilerplate code and moving logic to the client is especially useful for making bug diagnostics easier (I guess everybody using Spring has seen huge call stacks populated mainly by proxies while debugging), and intrinsically improves the app’s speed. Simple, stateless, mostly idempotent requests (the way REST says they should be) simplify logic and improve readability (simply because the logic to read is a lot simpler).

  13. Avatar  


    November 7, 2013 @ 5:10 pm

    What about Dropwizard? It’s a great framework that forces you to care about operations.

  14. Avatar  

    John Waterwood

    November 8, 2013 @ 10:03 am

    The JSF security review is not correct!

    JSF has a couple of important security features that you have seemed to miss.

    There is both implicit and explicit support for CSRF see in short there’s an explicit token for stateless views or general usage. For normal views there’s an automatic CSRF protection via the view state ID.

    Another important security feature is that JSF checks that you can only postback that what has been rendered. So if you render a list with “a”, “b”, “c” and then try to be sneaky and send “d” to the server, it won’t be accepted.

  15. Avatar  


    November 13, 2013 @ 12:54 pm

    Don’t think bringing out what UI options offered is relevant. As previous comments discussed client-side is HTML, CSS and JS (always has, always will) besides some developers nowadays the likes of @An0nym0usC0ward and I like to do it “properly”.
    The JS hatred thing is silly, JS is tested, is growing and maturing (more than Java) and mostly it IS the language of the browser. So simply wanna be a web-developer, go learn proper JS (GWT, Vaadin don’t cut it for me – they are just additional layers adding mostly complexities).

    One thing you forgot to mention, all of them need JRebel except for Play! which is a huge plus for me.

  16. Avatar  

    Lukas Eder

    November 17, 2013 @ 11:10 am

    I agree with others that ZK might need to be added, really. I don’t think it would be *that* much behind Vaadin in popularity.

    Besides, Implementing a very straightforward REST application with JAX-RS at the server side, and something like AngularJS (or name any other JS framework) seems quite as contemporary as some other choices. AngularJS catches up with any of Vaadin, Wicket, ZK, at least on Google Trends:

  17. Avatar  


    November 25, 2013 @ 12:24 pm

    I 100+ % agree with your vision on this one. I’m on the same road. But it will take some time before it will be common practice in the market.

  18. Avatar  

    Dilshod Sultan

    November 27, 2013 @ 6:47 am

    Hi, people, what do you all think about Play framework?

  19. Avatar  


    November 27, 2013 @ 6:56 am

    JRebel relevance wasn’t really considered. BTW, Grails can cope with hot updates too.

  20. Avatar  

    Dieter H.

    December 10, 2013 @ 11:11 am

    I don’t believe this at all. I’ve seen many, many web applications making your browser pretty much a JS fat client and I can’t say it’s very encouraging. Stuff like GWT that allows compile-time checks and unit testing of your JS is not so bad, but the fact is that larger applications like this tend to lock up quite easily, and as long as there is no uniform and large standard adhered to by every major player in the market, this will not be viable. That doesn’t mean I don’t support the idea, I can only hope a web framework will emerge that really sets the bar for corporate applications with a JS client, as this is really the best field of application for such a thing, but the fact is that at the moment, this doesn’t exist. Yet.

  21. Avatar  


    December 10, 2013 @ 6:46 pm

    I’ve delivered a few not so small apps built as a service layer on the server plus a rich and fat JavaScript client for the browser. None of them was locking up the browser.

    Some of them were rewrites of apps written using other technologies. The new implementations were both faster to develop and faster at runtime than the PHP/Wicket/tapestry equivalent.

    As for GWT in particular, I dislike it, for a few reasons: its maintenance is increasingly bad, and the JavaScript it generates is inscrutable. If you discover a bug in the generated JavaScript (which is something that happens), there’s not much you can do, aside from starting to debug the JavaScript generator. Similarly, if you hit a performance bumper, there’s not much you can do – the generated JavaScript is difficult to influence in any way.

    Besides, (aside from the ugly side of it) JavaScript is a wonderfully flexible and expressive language. Why would you prefer your code to be written in Java, which is in no way targeted at a browser execution environment, when you can write in JavaScript, on top of frameworks which add many powerful and convenient features for the web app developer?

    As for a likely candidate of a framework to develop corporate JS apps, check out qooxdoo. Its target is specifically the type of apps that you mention.

  22. Avatar  


    April 3, 2014 @ 11:10 am

    Let’s see, how ZK community is able to give a vote this time :)

  23. Avatar  


    April 3, 2014 @ 11:10 am

    I wander how much ZK votes the survey gets this time:

  24. Avatar  

    Mark Sasler

    September 6, 2014 @ 6:15 am

    There is an alternative tool similar to GWT called Dragome. But this one is about compiling bytecode to js, and it also has UI components support. Things like Incremental compiling, Java 8, HTML template are already supported.

    And there is no need to wait to ECMAScript 6 to be standardized because it already allows use of dynamic proxies continuation (js yield), classes, lambda (arrow functions).

    Project URL:

  25. Avatar  

    Serban Balamaci

    October 15, 2014 @ 11:34 am

    The fact that you even recommend qooxdo(who the hell uses it besides 1&1 – the fact that you were forced to use it, does not mean you should inflict it on others) and that you group Wicket in the same area as PHP and Tapestry kinda lowers you credibility. People can write bad performance apps in JS as well as any other language.

    Everybody is jumping into “The contemporary style of developing web apps is to build a set of services” – give it a few years when you’ll no longer be the one creating the webapps and if successful the business will get complicated, someone new might need to come and do maintenance on these apps and god help him making sense of which change involves which other part – because he’s not working in a static typed language, he might not have inherited 80% code coverage-, but hey he might be a lucky guy saying all needs to be rewritten from scratch.

  26. Avatar  


    October 15, 2014 @ 12:23 pm

    If you want to see who uses qooxdoo, browse their archived mailing list on nabble. I wasn’t forced to use it. I did a thorough research of what was available on the market at that time, and qooxdoo was the best choice to develop a web app with a team of people used to develop almost exclusively in Java.

    In the meantime, there are several other frameworks which you could use – ember, sproutcore, smartclient, you name it. Qooxdoo is still ahead of anything else, if you get to know it, IMO, but others have evolved hugely since that time. Qooxdoo just doesn’t have the marketing other frameworks have.

    I’d say you listening more to marketing hype than doing your own technical investigation of what you should or shouldn’t use lowers your credibility, not mine.

    I group Wicket, PHP and Tapestry together because they all do the same thing: generate markup on the server (granted, PHP can be used to implement services, but tapestry and wicket are specifically designed to generate the markup on the server). Generating markup on the server I call old style web app development. Anything JSP based falls into the same category. In fact, both server- and client-side libraries/frameworks that generate markup are IMO outdated – with HTML5 and the browser support there is for it nowadays, continuously replacing parts of the DOM from markup which needs to be parsed is impossible to be faster or more convenient than simply manipulating the DOM by mainly changing node attributes and only seldomly adding/removing nodes. The latter is what all client-side frameworks specifically targeted at rich single page apps rather than website scripting do.

    When you work with a loosely or dynamically typed language, and don’t have everything unit-tested, it’s your own fault. You can’t blame the language for the maintenance nightmare you create.

    Code coverage is a known bad measure for the quality of tests. When thoroughly practicing TDD, good tests are simply a side effect of what you do, and development speed goes up. If you refer to legacy code, you won’t get that code written in JavaScript anyway – JavaScript probably wasn’t considered a serious enough language to be used when that code was written.

  27. Avatar  

    Serban Balamaci

    October 15, 2014 @ 1:56 pm

    “Generating markup on the server I call old style web app development…The latter is what all client-side frameworks specifically targeted at rich single page apps rather than website scripting do.”
    Guess sites like amazon, alibaba are not interested in the performance boosts you get for clearing the DOM attributes vs replacing as they seem to not have adopted what you’re saying – Non SPA for them – (hopefully someone from them might see this thread and change this).

    “Qooxdoo just doesn’t have the marketing other frameworks have.” – ah, that explains the meager 400 stars on github.

    “You can’t blame the language for the maintenance nightmare you create.” – actually with java I don’t even need to look at the unit tests to see what is going on. I just need to follow in my IDE which method is calling which and all the places where the method I’m about to change gets called.

    I cannot explain how grateful I am right now that I’m programming Java and my colleague is in sick leave and without prior knowledge to the business case, I was able to work out fast what his code was supposed to do.

    Anyway, I cannot prove my case yet and will not continue arguing, time needs to pass, current “trendy” apps and frameworks to mature and grow big, developers need to leave, people to replace and maintain need to be hired and then tell their experiences and opinions.
    JS frameworks from my perspective are in their infancy and as soon as they mature, grow past some certain level it’s dubbed as heavy and dropped in the favor of the next “fly-light” framework.

  28. Avatar  


    October 15, 2014 @ 5:09 pm

    You said it right – Amazon and Alibaba have web sites, not apps (mostly).

    I would say the star count on github is definitely explainable by the lack of marketing – have you ever heard of qooxdoo before? Yet, you’re eager to trash it, without having tried it once, without even having looked at what the people actually using it say. Of course, Wicket, which is pure Java, fares much better: a whole lot 235 stars on github …

    As for qooxdoo’s trendiness: it’s already more than ten years old, still maintained and still highly appreciated by the small community around it (mostly people who don’t care about hype – and which regularly complain about the lack of marketing around it). A whole lot different history from GWT, which is another Java only solution …

    You can do the same following of method calls with JavaScript. Good luck, though, doing it with applications using clever runtime dependency injection when you stumble upon a method call to an interface method – only running through a debugger helps. Time spent in a debugger is mostly wasted time, once you start doing TDD properly. You don’t even notice how much so, before you try out TDD.

    But you go on using Java code to generate markup, if that makes you happy. I’ve done both (i.e. worked with plain JSP, Wicket and Struts, but also with qooxdoo, ext, backbone and a bit of angluar). I never ever want to go back to generating markup on the server, and I hate to use templates in JavaScript, even if it’s trendy atm.

  29. Avatar  


    October 22, 2014 @ 2:23 pm

    An important principle of the Unix philosophy is to do one thing and do it well. I fully embrace this. As a consequence, a framework like Play does too many things for my taste.

    Besides, it creates lock-in – you can’t easily switch from play to something else, neither can you swap out just part of what play provides for another implementation (like plugging in Spring security, for example). But I might be wrong – I didn’t do any real project with play so far.

  30. Avatar  


    October 29, 2014 @ 3:00 pm

    with reference to the following in the above comment ” its maintenance is increasingly bad, and the JavaScript it generates is inscrutable.” – being a GWT developer, I want to put my two cents across, any modern web application using GWT, uses the MVP/activity,places paradigm, which greatly alleviates the maintenance problem. As far as the JavaScript being churned out by GWT, being a Java developer (since you developed in GWT) it does not serve any purpose to to decipher the generated JavaScript (which is very optimized and complex), you need to go back to the Java code to modify. It is analogous to writing an app in C++ and debating how to understand or modify the machine code after compiling the C++ code.

  31. Avatar  


    October 29, 2014 @ 5:11 pm

    Quote: ” it does not serve any purpose to to decipher the generated JavaScript (which is very optimized and complex), you need to go back to the Java code to modify” – that’s the theory, and, given that the JavaScript GWT generates is indeed not all intelligible, you’re forced to apply it. The flipside is that when something really goes wrong, and you have no clue why, you have to rely on the GWT devs to fix it, and this isn’t always timely – I don’t comment on the reasons, these are anyway irrelevant when a customer is breeding down your neck. In such cases, instead of being able to diagnose the problem, you usually build a clunky workaround. Even if GWT later fixes the problem, you never remove the workaround – it no longer pays off, unless you have to start working on that particular place in code again.

    Conversely, when you write C++, and the compiled code doesn’t do what you’d expect it to do, you _can_ look at the assembly code, and that’s especially useful if you compiled with debug info. Similarly, you can inspect the .class files created from your .java files – which can also include debug info. I’m not aware of a debug mode compilation for GWT.

  32. Avatar  

    Santhana Gopala Homam

    February 19, 2015 @ 11:16 am

    This is amazing! Thank you.

  33. Avatar  


    February 19, 2015 @ 2:42 pm

    I wonder how ZeroTurnaround rated a framework like JSF. Does it look at something like PrimeFaces? As far as ease of use goes, I don’t understand why GWT is on the same level as JSF. A bare bone GWT (100% client side) is easy to develop for sure but when you introduce stuff like MVP, UIBinder, EventBus, etc, it is definitely not straightforward. You have to do a lot of wiring on your own. With JSF, once you set up the configuration, all you need to do is develop the .xhtml and the backing bean. The rest is taken care for you by the framework. For the app type CRUD, how come all the frameworks get zero when it comes to framework complexity, documentation, and code maintenance? Is it because those are irrelevant or because all the frameworks are the same in those aspects? Take documentation for example, I think GWT would rank lower than JSF.

  34. Avatar  

    Windows Unlimited Hosting

    February 20, 2015 @ 5:31 am

    Remarkable things here. I’m very glad to see your article.

  35. Avatar  


    April 3, 2015 @ 10:20 am

    Much thanks! It is an amazing web site.

  36. Avatar  

    Tomcat Cloud Hosting India

    April 28, 2015 @ 10:14 am

    Thank you I love it!

  37. Avatar  

    Cheap VPS Cloud Server India

    May 1, 2015 @ 9:52 am

    Thanks for making your blog.

  38. Avatar  

    Cheap Shared Linux Web Hosting

    May 4, 2015 @ 10:20 am

    Fantastic!! Awesome website.

  39. Avatar  

    Unlimited Reseller Web Hosting

    May 6, 2015 @ 10:07 am

    You’ve done a great job here!

RSS feed for comments on this post.

Leave a comment