ThoughtWorks Radar/ JSF on Hold

[fe...@planka.sk]

Hi there,

Any thoughts on recent ThoughtWorks radar update regarding JSF which I
guess implies ADF by default?
What should be the intelligent answer/feedback to this recommendation.

Ferdo

http://www.thoughtworks.com/radar/#/languages-and-frameworks/683

JSF
NEW
Hold
January 2014
We continue to see teams run into trouble using JSF -- JavaServer
Faces -- and are recommending you avoid this technology. Teams seem to
choose JSF because it is a J2EE standard without really evaluating
whether the programming model suits them. We think JSF is flawed
because it tries to abstract away HTML, CSS and HTTP, exactly the
reverse of what modern web frameworks do. JSF, like ASP.NET webforms,
attempts to create statefulness on top of the stateless protocol HTTP
and ends up causing a whole host of problems involving shared
server-side state. We are aware of the improvements in JSF 2.0, but
think the model is fundamentally broken. We recommend teams use simple
frameworks and embrace and understand web technologies including HTTP,
HTML and CSS.

[John Flack]

I've seen similar criticisms of JSF from others - another team at my company uses Wicket and some use Play.  They have a point - you can code more efficient layouts and have better control of layout if you do the View in HTML rather than JSF components.  This is especially true if you use HTML 5.  And you can give the view to web designers to do with tools like Dreamweaver.

Where it breaks down IMHO is in the Model and Controller layers.  I honestly believe that the base JSF controller, and better yet, the ADF Controller, are easier to use and faster to code, especially when combined with the ADF bindings.

So, what about the View?  Well, it turns out that Facelets, which is part of the JSF 2 standard, DOES allow you to code much of your layout in HTML, if that is what you want to do.  ADF 11gR2 and 12c include support for Facelets.  I am currently working on a template that is mostly HTML, but with the Facelets templating components, and so far, so good.  I'll give a more complete report later.

On Wednesday, February 5, 2014 8:03:06 AM UTC-5, frpko wrote:

Hi there,

Any thoughts on recent ThoughtWorks radar update regarding JSF which I  
guess implies ADF by default?
What should be the intelligent answer/feedback to this recommendation.

Ferdo

http://www.thoughtworks.com/radar/#/languages-and-frameworks/683

JSF
NEW

œHold

[SHAY SHMELTZER]

I guess they are entitled to that opinion but we could also easily say the exact opposite.

For example:
Instead of "We continue to see teams run into trouble using JSF"
We continue to see teams run production applications using JSF - just look at all the Fusion Apps and customer apps customers have in production with ADF (and other JSF implementations).

Instead of "We think JSF is flawed because it tries to abstract away HTML, CSS and HTTP"
We think JSF is great because it allows us to abstract from low level markup language and therefor switch UI technology when a better one comes along. For example 5 years ago the dominant UI technology for rich web UI was Flash - which is now all but gone and replaced with HTML5. What are all the people who built with Flash doing with their apps today?
We at Oracle have leveraged the component approach and enabled our developer to use the same component while updating the underlying UI technology - for example the graph components start in SVG, moved to PNG, then Flash and today HTML5. With no need to re-write the UI or learn a new markup language.

As far as that stateful/stateless - this really depends on what type of applications you are building. For intensive data interactions stateful makes a lot more sense.

Shay

--



Shay Shmeltzer| Director Product Management | +1.650.506.3081
Oracle Tools and Frameworks
200 Oracle pkwy, Redwood Shores, CA, 94065, USA

[Florin Marcus]

While being a Martin Fowler fan (the brain behind ThoughtWorks) I am willing to understand such statement only from the highest architectural level perspective.

Indeed, JSF is not the greatest architectural specification,  JSF lifecycle is so complex that no one  besides Steven Davelaar truly understands it.

But JSF is a just a specification implemented by lots of vendors, one of them being Oracle. To simply rule out all JSF implementations as a whole, is rather simplistic, it would be as if I would say that JEE Application Servers are a bad idea. These Nostradamus-type of statements are always popular, perhaps some of you missed that Java Is Already Dead.

JSF may be flawed, but the arguments for it are rather poor:

We think JSF is flawed because it tries to abstract away HTML, CSS and HTTP, exactly the reverse of what modern web frameworks do. 

Such statements usually come from people using Java Web Frameworks to build web sites (some might call them web applications). And when you build web sites, first step is for a web designer to create the html/css static layout, then developers to inject dynamic functionality into that html. Of course, this wouldn't work with any Component Based Framework, not only with JSF. A web designer first needs to 'learn' how UI components are constructed from html/css. However, this inconvenience in terms of design was solved in ADF's case with introduction of ADF Skin Editor and I've seen few web designers doing magic with ADF skinning in matter of hours.

However, most ADF applications I've seen doesn't involve much design, since standard ADF skins are brilliant from an ergonomic perspective, so besides few adjustments here and there, people tend to be happy with what they got. I would go further and say that an ADF application looks and behaves close to desktop/client applications, rather then a web applications, I rather see an ADF application as a desktop-client-in-a-browser, if that makes any sense. But how much design was it done for applications built on Oracle Forms or Swing, really? 

As for what modern web framework do, I have to admit I haven't being using any modern web frameworks in Java lately, since I moved to ADF in 2008.
But until that point, I have been using quite a few 'modern'  frameworks at their times: Struts, Webwork, Tapestry, JBoss Seam. I remember we started with Struts, then we dropped it in favour of more modern Webwork, who lately became Struts 2. But then, a topic started to make waves at the time: "Action Based Frameworks" vs "Component Based Frameworks", where the conclusion was (exactly the opposite of ThoughtWorks current remarks) that Component Based Frameworks are superior and the right way to move on. So, what we did at that point is to move from Struts 2(action-based) to Tapestry (component-based). Turned out not a great idea, since Tapestry author decided to drop Tapestry 4.1 (version we were using)  and started with Tapestry 5. from the scratch, without any migration option. So we again had to move to another component-based framework: JBoss Seam, but I recently found out that Seam development was interrupted by JBoss.

In conclusion: while it was fun switching between 'modern' web frameworks and developers gained a lot of experience from that, if you start building an application that may take years to complete, the last thing you need is your development framework to die before your application is even finished.  

As far as JSF being thrown out the window along with "ADF.NET webforms", this should only make ADF authors feel proud: ADF.NET is the most popular and mature web framework used for building business applications.

Florin

    

On Wednesday, February 5, 2014 1:03:06 PM UTC, frpko wrote:

Hi there,

Any thoughts on recent ThoughtWorks radar update regarding JSF which I  
guess implies ADF by default?
What should be the intelligent answer/feedback to this recommendation.

Ferdo

http://www.thoughtworks.com/radar/#/languages-and-frameworks/683

JSF
NEW

œHold

[Paco van der Linden]

Indeed, ThoughtWorks' post mentions the abstraction of HTML and CSS, but that is NOT the point at all. The issue they describe lies with the abstraction of HTTP. JSF (and ADF in particular) tries to abstract away the distance between the server and the client (browser), pretending they have a single shared state. This is why we have this super-complex JSF lifecycle in the first place. This is a great example of a leaky abstraction (in this case it is an abstraction with gaping holes if you ask me).

This particular trait of JSF is what the author of the post meant when he said the model is fundamentally broken. I must admit I agree. 

@Shay, you said: "For intensive data interactions stateful makes a lot more sense." I really don't see why. Could you elaborate on that?

Paco

[SHAY SHMELTZER]

Paco,

A typical data  interaction can be get a list of records, update some, insert others, delete others and then commit the whole transaction.
While doing this you might be navigating between pages in your app (List page to edit page and back).
In a stateless situation managing this complex synchronization of which data I got, what records I updated, which record I'm currently on and want to edit, what changes are in my transaction, and how I validate all the changes in one go can require you to code a lot of parameter passing and state monitoring.

With the way ADF does it, you get this out of the box.
I thikn a good read is the section about the Active Data Model of ADF here:
http://docs.oracle.com/cd/E16162_01/web.1112/e16182/bcintro.htm#sm0061

Shay

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
 
---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Florin Marcus]

Shay,
I don't think that ThoughtWorks had statefulness of Business Layer in mind  when criticising JSF.
They  focused entirely on Web technologies (or web frameworks),  so I think the question here is why JSF state is needed on the server.

In other words, why there is need of a JSF graph of UI components at all? 

After all, frameworks like GWT hide HTML and Javascript offering an Ajax-enabled, component-based Framework, without the need of UI server state.

There are quite a few web frameworks  that follow 'the other path':

1. Stateless business layer exposed as  REST webservices
 and

2. Various single-page, JS/AJAX based solutions that keep the state on the client  as JS variables , cookies or hidden input fields.

I may fancy a future ADF Faces implementation without JSF, using stateless business layer. Something like GWT. Or wait... maybe like ADF Mobile?   

[raman nanda]

Hi,

Vaadin does do that, but again from a performance point  of view everything is stored in session scope, so you'd have to manage the component state or memory cleaning yourself, if you move from one page to another.

Regards,
Ramandeep

[Paco van der Linden]

Shay,

I totally agree with you that any real application has to be stateful. You might say that a "stateless web application" is really nothing more than an ordinary website. My point (and that of the original post I believe) is not that you don't want state; of course you want and need state. It's just that you don't want your state to be "magically" and continuously shared between the server and the client in order to abstract away this inconvenient notion of client-server separation. Note that I'm talking about View/Controller state in ADF terms, which is more than just the Active Data Model of ADF BC.

Don't get me wrong. I think ADF is a great framework in the JSF world. And I think JSF is interesting and well thought-through. But that doesn't change the fact that the model it is based on is obsolete nowadays.

The capabilities (and performance) of browsers has increased so dramatically in the last decade that it has become unnecessary to keep any application state server-side at all. Everything ADF BC does (caching data fetched from a database, remembering row currency, simulating transactions and committing back to the database, etc. etc. etc.), everything ADF Controller does (TaskFlows, isolated transaction scoping, etc.) can be done client-side these days. (This is not in the original post, but simply my thoughts on the matter.)

It occurs to me that you refer to "parameter passing and state monitoring", which are terms that are really only applicable in "server-side-state situations". Have you looked recently at client-side-state frameworks? Have you seen how powerful they have become in the last few years?

For you information, I'm convinced of the power of ADF (having been the lead developer on several ADF projects in the past 6 years or so, I know ADF really really well). Some of the stuff you get for free in ADF is very powerful, but there is no technical reason another framework (e.g. a client-side framework) could not provide the same features.

Paco

[Paco van der Linden]

Florin,

Indeed! Wouldn't that be something... The powerful and rich ADF components in a pure client-side (JavaScript) implementation. That would be the best of ALL worlds. :-)

Paco

[Jeevan G Joseph]

Not to side track the conversation on the client-server state, but wouldn't JSF 2.2 features like stateless views address these concerns of the JSF framework always building statefulness on top of HTTP and how that is not desirable in some cases (Portal homepages for instance) ? 

Any time-frame when we can expect these (JSF 2.2 features) in ADF Faces ?

https://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless?force=255

Thanks,

Jeevan

please do not print this e-mail unless you really need to

[Blake Sullivan]

While this solution was easy to implement for the JSF team, I would question why it should be necessary.  In the case where the application isn't modifying the component tree, the goal should be that partial state saving doesn't save any state.

-- Blake Sullivan

[blake.sullivan]

Florin,

Is it really the component instances that you care about, or the idea that the server might be maintaining state for the component instances.  Other than the performance implications of creating the components instances for a particular request, I would care more about the session state.  As far as session state is concerned, my first preference would be to have none.  But if I have to have some, the less the better.

-- Blake Sullivan

[Florin Marcus]

Blake,

I was  referring to JSF graph instances as representing state held on HTTPSession, since View-Scope is nothing but Session-Scope with automatic removal.

Moreover, while JSF state can be kept on the client (javax.faces.STATE_SAVING_METHOD=client) , why storing JSF graph between requests still needed at all?

I would understand it might be required for preserving DataModel in other JSF implementations, but why for ADF Faces + BC,  where JSF model is delegated to BC layer?

[Blake Sullivan]

In theory, with partial state saving, you wouldn't have any state in the session for the graph if your code (or potentially its renderer) didn't programmatically modify it.

-- Blake Sullivan

[Paco van der Linden]

A recent post by John Munch explains the "problem with JSF" in a few more words: http://johnmunsch.com/2014/02/22/why-we-abandoned-server-generated-web-pages/

Paco.

[Blake Sullivan]

Bruno,

I understand the general complaints regarding server generation, however it would be helpful to separate the problems endemic with server generation from any additional problems that JSF introduces.  The complaint about session-persisted component state is specific to JSF, for example.

-- Blake Sullivan