Casper, I think this is the first time that we've agreed on something. Although, as much as I generally like to avoid the classic server-side HTML generation web framework, there are some scenarios where it makes sense. For example, Wikipedia and all the major blogging systems use server-side HTML generation frameworks, and I suspect that model fits those applications and they wouldn't be better served by the client-JavaScript app approach.
On Sunday, September 9, 2012 2:56:26 AM UTC-5, Casper Bang wrote: > > I'd have to agree with that approach, but I'd also try to explain a bit > more about why. > > Traditional web frameworks try to do too much emulating classic MVC/MVP > and ends up not doing a very good job at all, adding countless > abstraction layers like life-cycle management, session management, > templating, expression language etc. Some later hybrids like GWT tries to > unify the experience further, by pushing state and business logic out on > the client. However, cross-compiling and shielding the developer further > only gets you so far - eventually you end up acknowledging the undeniable > truth, that the web consists of a server delivering content to a client > which is then rendered via HTML/CSS and JavaScript! > > By writing your application backend as a stateless REST service, and > hooking some arbitrary application layer on top of these, you've set > yourself up for success down the line. The backend need only consist > of glorified servlets, that can be replaced by any other HTTP technology > if/when desired (I.e. Jersey/JAX-RS replaced by node.js). By being > stateless, it can scale horizontally rather than vertically. By having a > clear responsibility (serving up data) it can be configured as per an > aspect fashion with various filters in front (caching, compression, > security, conversion, auditing, logging etc.). By being detached from the > frontend, it can be reused by other frontends or even as a B2B gateway > (I.e. Mobile JQuery for smartphones, native smartphone frontends etc.). > Hell, it can even form the basis of a unified data engine complete with > query language and AST optimizer for extracting and transforming data from > the underlying resources (I.e. the OData protocol) without some clunky ORM. > > Jersey + JQuery (Mobile) is hard to beat in regard to maintainability, > flexibility and performance. Keep it simple, use Java where it makes sense, > but don't aim for the world to be completely wrapped in Java as is the > traditional conservative pseudo-religious view of many. :) > > /Casper > > On Sunday, September 9, 2012 1:31:29 AM UTC+2, clay wrote: >> >> The other option that I would consider is Java web services using >> something like Jersey tied to a HTML+JS front-end using JavaScript >> frameworks like ext-js or google-closure without a server-side html >> generation framework. I've been working on a lot of those applications and >> I find it fits a lot of applications very well. >> > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/7aRCjVDocSAJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
