Building Web 2.0ish web applications

[Markus Backman]

Hi

Where I work there is an ongoing debate on how the company should build it's web applications in the future. The company is a large financial company and the company has a large number of Java developers. The current web applications is built upon Web 1.0 style, multipage and no AJAX. To give the customers a better experience there is need to move to a Web 2.0ish style with more of a singlepage application.

The technology choice is being debated at the moment and the different choices are:

* REST style JSON/XML services + some JavaScript framework(s) on the client.

* Portlet 2.0 (JSR 286) + JSF 2.0 (JSR 314)

There is no shortage of REST style + JS framework web applications out on the Internet so that seems a rather popular approach. But what I haven't found is some site that uses Portlet + JSF and combining it to a good Web 2.0ish web application. Anyone that knows of such an application that can point me in that direction?

Any experiences and thought are welcomed.

Best regards,

Markus 

[Lukasz Plotnicki]

Hi,

regarding the first choice: JavaScript-based client. Considering the large in-house Java developers number, you may consider evaluating GWT (https://developers.google.com/web-toolkit/). In my opinion it is perfectly suited for larger teams and projects.

Best wishes,

Lukasz 

[Markus Backman]

Hi

Yes that is a valid thought and something that may be taken into consideration. But using REST + JavaScript opens the possibility to only use web developers to create the front end and using Java Developers for the services. 

So it seems that it is hard to find a good portlet/JSF2 website? anyone?

/Markus

[Casper Bang]

The topic has been discussed in the past on this group. My experiences and view boils down to:

- Most Java front-end tech tend to rely far too much on session scope (JSF is a major sinner while GWT is an exception) and creates a massive dependency chain where complexity thrives.

- No matter how well the browser aspect is abstracted away, you are *always* going to need some HTML/CSS/JavaScript skills anyway.

- Consciously separating Model and ViewController at the transportation layer makes it easier to scale, allows you to mix technologies and even reuse the services for other things (say B2B scenario or a mobile client).

So I would recommend spending a few hours with Jersey generating JSON, and jQuery Mobile building a simple UI consuming this JSON, to get a feeling for the approach I advocate. Services can be mocked simply by writing a piece of JSON and the simple dependency chain makes it super fast to compile and produces tight artifacts (your Java developers might develop a post-traumatic disorder but they still get to write Java services, servlet filters and create WAR's).

/Casper

PS: GWT is not bad, but the second item above still applies and it's can get quite slow to cross-compile a large project. GWT also has the problem that the POJO service request aspect is unpolished (notice how SmartGWT, GXT etc. all try to wrap their own incompatible mapping solutions). 

[James Ward]

I definitely think the future of web apps are more Client/Server-ish...
JavaScript on the client for the whole UI talking to stateless RESTful
JSON on the server. But the toolchain for building these kind of apps
is somewhat immature today. It's evolving quickly so things will be
pretty different 2 years from now.

At JavaOne this year I did a presentation about this new modern web app
architecture. The video has been posted:
http://www.jamesward.com/2012/10/17/javaone-video-client-server-apps-with-html5-and-java

As far as portals go... I believe that CORS will open up new
opportunities for client-side app aggregation. The server-side portal
model really doesn't play well with apps that have their UI / state on
the server. Once CORS is more ubiquitous we will probably see a new
generation of mashup / client-side portals appear.

Everything we've done with the web UI on the server is currently being
rebuilt to run on the client via JavaScript. Fun times! :)

-James

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

[Fabrizio Giudici]

On Thu, 18 Oct 2012 17:12:53 +0200, James Ward <james...@typesafe.com>
wrote:

> I definitely think the future of web apps are more Client/Server-ish...
> JavaScript on the client for the whole UI talking to stateless RESTful
> JSON on the server. But the toolchain for building these kind of apps
> is somewhat immature today. It's evolving quickly so things will be
> pretty different 2 years from now.

This is agreeable (for the relevant contexts), but we should also be aware
that architectures have had a flip-flop attitude in the past years.
Client/Server was also the apparent trend fifteen years ago, then things
changed, and then changed again. I would not bet a single eurocent that
within two years things will stay the same.



--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[Casper Bang]

On Thursday, October 18, 2012 6:34:19 PM UTC+2, fabrizio.giudici wrote:

This is agreeable (for the relevant contexts), but we should also be aware  
that architectures have had a flip-flop attitude in the past years.  
Client/Server was also the apparent trend fifteen years ago, then things  
changed, and then changed again. I would not bet a single eurocent that  
within two years things will stay the same.

For sure, trends come and go even in our geeky world. However, the world is getting more heterogeneous and I don't really see what would make the pendulum swing back - certainly not in two years from now. We went from modal applications based on 80x24 ASCII characters, to windowed desktop applications, to model2 browser applications and now finally to native mobile iOS/Android apps. With devices getting more and more diverse and embedded service consumption moving into printers, TV's, set-tops etc. I don't see the current HTML5/Ajax model (Canvas, LocalStorage, WebSockets etc.) going away anytime soon. And really, I doubt very many are going to miss Swing, Silverlight nor Flash.

[Ricky Clarkson]

Wake me up when you can write to a DVD drive from HTML5.

Desktop apps have their problems but I believe they're more in
security than straight ugliness/difficulty. Who wants to run my
random exe file compared to navigating to my random web page?
Virtually nobody, because the OSs don't sandbox applications, they
sandbox users. That needs fixing, plus the requirement of admin
rights to install apps needs removing, then we can eliminate this
pointless web/desktop boundary and start writing more straightforward
code again.

> --
> 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/-/2OVZw4raOOsJ.

>
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to

> javaposse+...@googlegroups.com.

[James Ward]

I believe this is possible today via PhoneGap-ish Desktop App frameworks
and with Windows 8 you can build desktop apps with HTML5. Ubuntu is
also working on making desktop apps from web technologies. As well as
Chrome OS. :)

HTML5 will soon be the most ubiquitous UI technology for web, desktop,
and mobile apps. :)

-James

[Fabrizio Giudici]

On Thu, 18 Oct 2012 22:17:22 +0200, James Ward <james...@typesafe.com>
wrote:

> I believe this is possible today via PhoneGap-ish Desktop App frameworks
> and with Windows 8 you can build desktop apps with HTML5. Ubuntu is
> also working on making desktop apps from web technologies. As well as
> Chrome OS. :)
>
> HTML5 will soon be the most ubiquitous UI technology for web, desktop,
> and mobile apps. :)

I've seen this assertions multiple times in the past for a number of
technologies. Smileys included :-) And it happened to be true that each
technology allowed this and that, but by that time fashion said that it
was the turn to redo everything in a new cool technology. People asserting
that now it will be different are much like people saying that history was
ended in 1989.

> On Thu, 2012-10-18 at 16:20 -0300, Ricky Clarkson wrote:

>> Virtually nobody, because the OSs don't sandbox applications, they
>> sandbox users.

Actually, Mac OS X Lion does application sandboxing, but at the moment I
don't know much about it.

[SK]

Hi!

Honestly I think the reason why it is hard to find single page JSF applications is that there is hardly any to be found.

We gave JSF a shot, but after a while we had to switch to a different framework (we picked lift but I know others that used wicket).

A different take on your problem is the amount of server state you want or don't want to handle.

Good luck!

Stein Kåre

[Markus Backman]

I agree that HTML5 is the way forward. And I also believe that a more client/server approach with API calls is the way forward. But I would like to have more than belief to base the decision upon. Therefore I am interested to see if anyone has managed to create a good HTML5 web 2.0ish site with the Java standards, JSF and portlets. But based on the discussion no one seams to know any :).

[Fabrizio Giudici]

On Fri, 19 Oct 2012 13:01:25 +0200, Markus Backman
<markus.b...@gmail.com> wrote:

> I agree that HTML5 is the way forward. And I also believe that a more
> client/server approach with API calls is the way forward. But I would
> like
> to have more than belief to base the decision upon. Therefore I
> am interested to see if anyone has managed to create a good HTML5 web
> 2.0ish site with the Java standards, JSF and portlets. But based on the
> discussion no one seams to know any :).

... probably because most people who goes the HTML5 way don't use JSF any
longer? Are JSF a strict requirement for you?

[Markus Backman]

There are to camps within the company, REST+JS or JSF2+Portlet2... I am just trying to gather some information on the dark side (JSF2+Portlet2) so sharpen my arguments why we shouldn't go down that road.

[clay]

On Tuesday, October 16, 2012 2:25:59 AM UTC-5, Markus Backman wrote:

The technology choice is being debated at the moment and the different choices are:

* REST style JSON/XML services + some JavaScript framework(s) on the client.

* Portlet 2.0 (JSR 286) + JSF 2.0 (JSR 314)

I'm working on a team doing the REST style. Our server-side services use Java + Jersey + JSON + REST. If we were starting over, the team would prefer Scala but Java is adequate. Our GUI is pure HTML/JS with various JavaScript frameworks. The whole team likes this approach.

I had lots of experience with JSF 1.x and Facelets and it was horrible. I haven't used JSF 2.0 (although I have used Facelets quite a bit), but before I spend a large volume of time doing deep learning and evaluation, I want to see a high level justification that that effort may be worthwhile. JSF 2.0 doesn't seem to have that high level justification. I haven't heard of any success stories, I haven't heard any excitement or high level features or value, and it doesn't seem to be getting much community interest. If you want to argue against JSF 2.0, those are the reasons I would use.

I've also used GWT. I would avoid that. First, it adds a large, slow build and tooling step. Secondly, there is a huge difference between your Java source and the generated JavaScript. Other JavaScript compiled languages such as CoffeeScript or Dart or possibly TypeScript offer much lighter and transparent translation. You can look at the generated JavaScript and immediately see how it maps to the original source. Lastly, notice that even Google only uses it on a few obscure web sites. None of Google's major web sites use it. They do use the Google Closure JavaScript libraries, which are pretty good.

[Fabrizio Giudici]

On Fri, 19 Oct 2012 17:38:05 +0200, clay <clayt...@gmail.com> wrote:

> excitement or high level features or value, and it doesn't seem to be
> getting much community interest. If you want to argue against JSF 2.0,
> those are the reasons I would use.

JSF 1.0 was very different than 2.0, so it's meaningless to compare it.
Latest JSF are perfectly usable, indeed they are used much more than most
people think (banks use it very much) and there are people who like it for
tooling. I wouldn't call it such a bad thing. My point is that other
technologies are better from the simplicity point of view.

>
> I've also used GWT. I would avoid that. First, it adds a large, slow
> build
> and tooling step.

Correct, but with Vaadin you save that step, even though by giving up with
some features.

> Secondly, there is a huge difference between your Java
> source and the generated JavaScript. Other JavaScript compiled languages
> such as CoffeeScript or Dart or possibly TypeScript offer much lighter
> and
> transparent translation.

But what's the problem here? My take on this is that JS generated by those
tools is no more no less than bytecode. I don't read generated bytecode. I
only care that it works.

[Vince O'Sullivan]

On Friday, 19 October 2012 16:38:05 UTC+1, clay wrote:

I had lots of experience with JSF 1.x and Facelets and it was horrible. I haven't used JSF 2.0

Experience with JSF 1.x is not a good basis for judging JSF 2.0.  They are just too different.

Waiting for other people's success stories isn't a good strategy either.  When was the last time you heard a Java success story? 

In fact, I'd go so far as to say the qualities of a software development language as a language are not a basis for choosing to use it.  If it was then neither JavaScript nor Objective-C would be in use today.