On Sun, 09 Sep 2012 09:56:26 +0200, Casper Bang <[email protected]>
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. :)
I like this analysis, but it's incomplete from my point of view. The
criterium I use to distinguish web frameworks that I might like or not is
the presence or absence of push updates. Actually, when you write "the web
consists of a server delivering content to a client", the problem is that
it often does with a pull approach, which to me imposes too severe
limitations to design, as harmful as those unnecessary life-cycle
complications etc... Of course the web 2.0 can do pushes with different
implementations, that I don't care of and I dont' want to care of. I want
my framework to support it. From this point of view GWT is superior, but
with the cited cost of development complexity. Vaadin is an excellent
trade off (the cost to pay is to accept client-server interactions for
almost everything you do in the client). If you want push updates, a
(glorified) servlet is not enough.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
[email protected]
http://tidalwave.it - http://fabriziogiudici.it
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
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.
