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

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. m.google.com
  • 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

  • Simon Maple

    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”! http://www.youtube.com/watch?v=oIu15zIsjQg

  • Oliver White

    It’s true! I’ve spotted him!

  • Joe

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

  • salk31

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

  • kpolo

    +1
    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”!!!

  • salk31

    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.

  • arhan

    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.

  • shal

    +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.

  • salk31

    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.

  • David Nouls

    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.

  • Subhro

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

  • An0nym0usC0ward

    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).

  • Eric

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

  • John Waterwood

    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 http://jdevelopment.nl/jsf-22/#869 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.

  • http://elnibs.wordpress.com/ elnibs

    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.

  • http://www.jooq.org Lukas Eder

    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:

    http://www.google.ch/trends/explore?q=vaadin%2C+wicket%2C+zk%2C+angularjs

  • John

    Hi,
    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.
    Cheers

  • Dilshod Sultan

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

  • arhan

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

  • Dieter H.

    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.

  • An0nym0usC0ward

    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.

  • arhan

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

    https://rebellabs.typeform.com/to/BTGaVf

  • arhan

    I wander how much ZK votes the survey gets this time: https://rebellabs.typeform.com/to/BTGaVf

  • Mark Sasler

    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: http://www.dragome.com

  • Serban Balamaci

    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.

  • An0nym0usC0ward

    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.

  • Serban Balamaci

    “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.

  • An0nym0usC0ward

    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.

  • An0nym0usC0ward

    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.

  • Mqurashi

    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.

  • An0nym0usC0ward

    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.