Dropwizard is where it's at right now for Java frameworks. It's a superproject that glues together the best pieces out there. Surprised it wasn't on the wikipedia list.
Which brings up another point: if we're talking about web frameworks for the next decade we should really be looking at service-oriented architectures / single-page apps or whatever you want to call that model. It's quite different from the web frameworks of yesteryear that generated UI on the server. Dropwizard can do web views but it really positions itself as a REST service framework.
So, that brings javascript frameworks into the consideration. And the author has a paragraph where he just dismisses it as a "terrible hack"...??? I think that is going to seriously hamper the outcome here. It's good that modern web apps leverage the power of the browser and JS frameworks are the way to do that.
That may be what you want right now but the article is about something that will last 10 years. And what constitutes a "standard web app" is definitely shifting and will likely solidify over that time. "Fat client" isn't really the best term for it, because the client code is usually pretty lightweight. I'd say "modern web app".
I'd be including a consideration of AngularJS, Backbone, Ember etc. + a service-oriented backend framework like Dropwizard. That's also incidentally how you'd architect your backend support a native mobile client, which is a good thing to prepare for even if you think you only need an HTML frontend right now.
The "cutting-edge" web frameworks that already exist today are the fat client frameworks you describe (client-side rendering). The web frameworks of the future will have robust server-side and client-side rendering, in my opinion. We're already seeing a little bit of this with Airbnb and Rendr for Backbone, React, and Twitter's web app, but it's not quite there.
> Don't forget that old style web apps are basically REST frameworks that render content with a content type of text/html...
They really aren't. A REST API wants to be simple and orthogonal; if you want two different pieces of data you make two different calls, so they're well suited to the "one controller per URL" paradigm. A traditional web app needs to combine and reuse components on every page (e.g. you might have a "messages" widget or a "user info" widget, which you would want to be encapsulated with their own logic), so you need better support for composing together different pieces of logic, and a single controller no longer makes sense.
It's interesting but I don't know about 10 year longevity. I guess because it doesn't score super great in benchmarks, does bytecode hacking / is not standard Java, and all really just to focus on making those initial stages of a project a little easier.
Dropwizard is still pretty easy to use for a Java developer but has the advantage of being standard Java and pulling together the very best open source projects out there.. so it inherits the communities and experience around each of those projects. That probably has better prospects in the long run.
I mean even if Dropwizard goes away, it's basically a glorified bundle of those projects which already have multiple years and tons of usage behind them.
Play does seem to have a burgeoning community though but it's too early to tell whether it's "take over the world" or "go the way of Scala".
Which brings up another point: if we're talking about web frameworks for the next decade we should really be looking at service-oriented architectures / single-page apps or whatever you want to call that model. It's quite different from the web frameworks of yesteryear that generated UI on the server. Dropwizard can do web views but it really positions itself as a REST service framework.
So, that brings javascript frameworks into the consideration. And the author has a paragraph where he just dismisses it as a "terrible hack"...??? I think that is going to seriously hamper the outcome here. It's good that modern web apps leverage the power of the browser and JS frameworks are the way to do that.