Riff reguest - web frameworks

[Fergus Nelson]

Hi Posse,

I have been really enjoying the recent run of riffing on a particular area of java. The one on build tools was really informative. Can I please request that you guys do a session on web frameworks?

Thanks

Fergus

[Jan Goyvaerts]

That will be a very long episode ! :-)

Fergus

--
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/-/-Ezop1SDBi4J.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[phil swenson]

not if they just pick the good ones.  there are like 2 :)

[Jan Goyvaerts]

oh really ? Come on, dare to start the storm by telling which. :-p

[phil swenson]

well one isn't even java really:  grails.

The other one is Play.  And now Play is Scala based.  So maybe there are zero :)

I'm not aware of any others that don't make me cringe.

[clay]

Play definitely counts as both a Java and Scala web framework. The HTML templates use a Scala DSL, and the Play framework requires Scala and SBT, but you can write all of your controller classes and back end logic in either Java or Scala. Java is definitely a fully supported language.

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.

[Casper Bang]

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

[Fabrizio Giudici]

On Sun, 09 Sep 2012 09:56:26 +0200, Casper Bang <caspe...@gmail.com>
wrote:

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."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Casper Bang]

I too can see a need for polling or long-polling using XMLHttpRequest. However, I don't consider keeping a GET request persistently open, misusing it to push updates back, as particular beneficial or scalable?! Perhaps you are talking about some other mechanism in HTTP, in which case, can you point me to a RFC?

/Casper

[clay]

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.

[Fabrizio Giudici]

On Tue, 11 Sep 2012 18:49:27 +0200, clay <clayt...@gmail.com> wrote:

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

It depends on whether you have a webapp vs website (there was a thread
about this a few time ago).