4 ms·

>Dropwizard can do web views but it really positions itself as a REST service framework. That would eliminate it for me. Not everyone is coding APIs and fat c

>Dropwizard can do web views but it really positions itself as a REST service framework. That would eliminate it for me. Not everyone is coding APIs and fat client web apps. I'd prefer a framework geared up to do standard web apps as well.

abalone 12y ago
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.
- brianchu 12y ago
  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.
pling 12y ago
It does standard good old fashioned web apps as well: https://dropwizard.github.io/dropwizard/manual/views.html https://dropwizard.github.io/dropwizard/manual/views.html Don't forget that old style web apps are basically REST frameworks that render content with a content type of text/html...
- lmm 12y ago
  > 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.
  - pling 12y ago
    Fair point there! JSF it is :(

abalone 12y ago

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.

brianchu 12y ago
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.

pling 12y ago

It does standard good old fashioned web apps as well: https://dropwizard.github.io/dropwizard/manual/views.html https://dropwizard.github.io/dropwizard/manual/views.html Don't forget that old style web apps are basically REST frameworks that render content with a content type of text/html...

lmm 12y ago
> 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.
- pling 12y ago
  Fair point there! JSF it is :(