Skip to main content

Grim or Bright future to JSF

10 replies [Last post]
vladperl
Offline
Joined: 2004-08-11

Hi folks,
I have prepared new kind of strategic plan for JSF and I really need your participation on it.
To push you in action let me apply some scare tactics :
If my calculations are correct in a couple years the JSF framework could become pretty irrelevant to the market.
Here is my pretty basic argumentation:
1) Rocket rise web platform. Good examples are rapid browser progressing, quick adapting HTML 5, and emerging web platforms such as Google Chrome OS or IE9 Platform.
It means drastically improved client side. So client side oriented frameworks will get more advantage comparing to server oriented framework such as JSF.
2) Establishing JavaScript based server platform. Improvements in area of ECMAScript standards, implementing crazy fast JavaScript engines, CommonJS and Node are enough examples to see that it's coming.
3) Huge rise in popularity JavaScript libraries. Many of them provide rich set of UI components, have capable template engines and have started move to server side.
Also take in account that web development oriented sites (sitepoint.com e.g.) have stopped to write Java related stuff several years ago.
4) JSF team is small and has very limited resources.
5) Recently announced Google's native client now supports the three most popular processor architectures.

Let's be clear on one main point.
Incremental improvements to JSF framework will not turn the situation for better because JSF framework will continue to lose ground in the same time from technological and market perspectives.
To reverse the situation we have to change drastically our approach first of all from technological point of view.
That certainly wouldn't enough to win but that will provide solid ground to attack the market place.
Keep in mind even if we will have the framework that technologically is superior to others there is still no guaranty that market will share our opinion on this.
Anyway establishing a new marketing strategy for JSF is the topic that can follow only after high potential technological plan is in place.
Usually in every situation there is a way out.
We still have the chance to turn the future to our advantages.
The most critical step is to make JSF more balanced between client and server sides.
I mean we have to move all UI components from server to client.
Yes, I know there is a huge amount of work absorbed in the related functionality but sometimes surgery is the best available option.
In this context the phrase "kill them all" sound right to me.
It's understandable if JSF components library vendors will try to kill the idea.
From another hand if they will be able to embrace it they could open much bigger playing field for itself from the market perspective.
I suggest to introduce a new kind of JSF components called "data controls" and they main responsibility to support only data handling oriented functionality.
They should completely disconnect from UI related functionality.
UI specific functionality belongs to client side like it was before in desktop based applications.
Regarding how the plan was born I have to say that I just took a look around and made some connections, interpretations and extrapolations.
Take in account that almost all points of the plan were originally suggested before by others developers.
The plan is still in early stage but there is enough data to support or disregard it.I would like to see any opinion here even angry one.
I strongly believe that JSF team would like to know what community thinks about the future of JSF.
In case you are pretty busy or taking passive position still find a couple seconds and send a signal for example:
"-1", "0", "1".

See the following link:
http://wiki.jcp.org/wiki/index.php?page=JSF+Proposed+Features

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Ed Burns

>>>>> On Wed, 24 Mar 2010 07:49:45 -0700 (PDT), webtier@javadesktop.org said:

VV> iconv: (stdin): cannot convert
VV> Hi Jan-Kees,

KJV> JSF doesn't put any restriction on the way you write components. If
KJV> you prefer JSP, FreeMarker or whatever, it can be implemented.

VV> I doubt that current JSF architecture allow adapting for example
VV> FreeMarker as complete replacement for JSP or facelets.

Actually, that sort of thing is *precisely* what we designed the JSF2
View Declaration Language API to do.

JKV> but since 2.0, you can even write components using only markup.

VV> I believe you mean only composite kind of components can be written
VV> using only markup language. You will have hard time to implement
VV> such components as h:inputText or h:selectOneMenu using only markup
VV> language.

The EG reasoning here is: if you can't write everything you need as a
composite component using markup+JavaScript only, depending only on the
HTML_BASIC component set as your base level of JSF UI component, then
composite components need some improvement.

Do you have information to suggest where we need to improve it that I
don't already know about?

Ed

--
| edward.burns... | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

vladperl
Offline
Joined: 2004-08-11

ED>Actually, that sort of thing is *precisely* what we designed the JSF2
ED>View Declaration Language API to do.

I have impression that such thing as implementing of VDL is hard to implement for average developer.
It would be useful to have support for JavaFX as VDL in standard JSF implementation.
Also it would be very impressive to see if the same VDL can be used to generate both desktop and web UI.

ED>The EG reasoning here is: if you can't write everything you need as a
ED>composite component using markup+JavaScript only, depending only on the
ED>HTML_BASIC component set as your base level of JSF UI component, then
ED>composite components need some improvement.

ED>Do you have information to suggest where we need to improve it that I
ED>don't already know about?

In this case problem is with base level.
Until we stop using HTML_BASIC component set easy integration with Javascript libraries will be problematic.
It would be great to have basic set of client-side components as alternative to HTML RenderKit.

Vladimir

vladperl
Offline
Joined: 2004-08-11

Hi Jan-Kees,

>JSF doesn't put any restriction on the way you write components. If you prefer JSP, FreeMarker or whatever, it can be implemented.

I doubt that current JSF architecture allow adapting for example FreeMarker as complete replacement for JSP or facelets.
Probably you mean possibility to use additional markup languages strictly for templating purposes.
But I fail to see how is possible to write components with different than facelets markup language.

>but since 2.0, you can even write components using only markup.

I believe you mean only composite kind of components can be written using only markup language.
You will have hard time to implement such components as h:inputText or h:selectOneMenu using only markup language.
There is one very important thing related to using different markup languages.
It could be a little bit confusing in some aspect.
Let me try to explain what I mean.
Markup language can be used strictly as language directly connected to template engine. Good example is XSLT.
Another case when markup language could be used only for describing UI.
The term "view description language"(VDL) describe the second case.
I suppose that JSF oriented on support only one connection between VDL and related rendering process.
But in case of JavaFX we could try to use it as VDL but without hard coded connection to rendering technology.
What I’m trying to say that if JSF will follow approach described in the plan someday it will be possible to use practically the same JSF application to render web application or desktop application :)
This kind of power impossible until we remove rendering functionality from java components. After all the main purpose of the server-side is to serve data handling and logic not align to requirements of UI components.
What we have now is that server is servant of client.
You know better than me how much UI related java code located on server-side.

>You're talking about the programming model (@compile time). I was talking about the runtime characteristics. GWT compiles into JavaScript and has stateless server side services. JSF is a server side framework. That's a very fundamental difference.

You are right. It’s really fundamental difference and in this respect GWT has advantage in my opinion.
Now I understand why you have pointed to GWT.
From another hand it’s one more argument to support the plan :)

>GWT uses a specific kind of remoting mechanism to let the client communicate with the server. JSF uses POST (or GET/"Ajax" since 2.0) for everything. This is very different.

I agree it’s different and it have to be considered even it’s definitely less important difference than previous one.
Anyway you pushed me in direction to create some kind of table where we can present JSF position among other frameworks.
Using the table we will see current position of JSF and future position of JSF according to the plan.
This way there is chance to see more precisely if future version of JSF will hold indeed distinguish position.
Call it marketing positioning for JSF.

>Where state management is implicit in an Ajax application (the state is in the DOM and the DOM is kept alive across requests),
>state management is one of the key features of JSF (and this is necessary, because it's a server side application).

Having UI component state management on server-side in my opinion one of the biggest problem of JSF.
In this regard I suggest to do the same thing that GWT do - keep all UI components on client-side.
To illustrate majority of the problem see the following fragment from Alexander Smirnov’s letter:
"The problem is far worse then you think :-( UIData itself has transient
properties, the most important of them is dataModel. Standalone UIData
caches model between phases, but resets it if you have enclosed
iteration components that gives huge impact on performance if data model
does not cache results itself. In Mojarra, UIRepeat knows about UIData
but latest has no clue about repeater, so if you put data table inside
the , results will be unpredictable."

Also it is interesting to see how ICEfaces is fighting the problem:
"ICEfaces renders into a server-side Document Object Model (DOM) with only incremental changes to the DOM being delivered to the browser and reassembled with the light-weight Ajax Bridge . This is a revolutionary technique known as Direct-to-DOM (D2D)."
That what I mention before - the server-side is trying to adapt, align, repeat/replicate/imitate client-side functionality.
I would call it dancing around functionality :)
One more other developer's comment that is not require much explanation in the current context:
IS> I still think about some kind of representation of the component tree on
IS> client in some Javascript API.

>Maybe someone else can correct me here, but JSF is limited to markup that is rendered by the browser, like HTML. I think implementing a RenderKit for JavaFX is very difficult with the current framework, because it impacts almost all other parts of the framework.
>For example, if I understand your proposal correctly, phase 1, 2 and 6 can be removed. And I'm sure there are big implications on the other parts.

Only reason is that currently both facelets and JSP are hard coded to servlet/JSF life cycle.
Of course you could use some kind of work around to use JSF for different purposes than render HTML.
In fact my application already using JSF to render HL7 messages and I know that people use JSF to render PDF and other stuff.
It looks like part of the plan "Possibility to run facelets outside JSF context" has some support inside JSF team.
So hopefully soon the situation will be improved in this regard.

>I think implementing a RenderKit for JavaFX is very difficult with the current framework, because it impacts almost all other parts of the framework.

That exactly is my point. That why it doesn’t make much sense to try to integrate JavaFX without implementing phases 1,2,4 and 5.

>For example, if I understand your proposal correctly, phase 1, 2 and 6 can be removed. And I'm sure there are big implications on the other parts.

These are the most important parts and without them the plan will lose much value.
You effectively killed my argumentation for this part of debate with your Scala support ;)

>But you're suggestion sounds to me like changing something well-balanced to something less-balanced.

It’s hard to discuss this part without a clear criteria’s in place.

>So you're saying: Let's rewrite a very large portion of JSF 2 but keep the old stuff?
>This doesn't sound like a good idea to me.

It’s hard to define precisely on this stage what to keep and what to throw out.
Personally I’m very radical in this respect.
But Ed Burns will do everything in his power to keep the old stuff in order to have backward compatibility in place.
So I don’t really bother to think precisely regarding this matter.

>I also don't think the comparison with the 1.2-2.0 migration is valid, since 2.0 works the same as 1.2 if you used Facelets. You get some extras with 2.0, but your application still works fine without them.
>You can simply start using one feature at a time, for example starting with an event tag, adding some Ajax support and then migrating to bean validation, one page at a time.

To some degree you are right, but I still think it’s possible to have smooth migration even with so radical changes.

>I don't see this simple migration path in your strategy, because some of the fundaments are either removed or changed. As said, his didn't happen in 2.0.

I have some ideas in this regard but I need to work more on it.
One of idea is that simple configuration change could put application in mode using complete Ajax lifecycle instead of traditional JSF lifecycle.

>My main concern regarding those rich clients is that they are more powerful than JavaScript will be.
>They have big advantages with the programming model (in Flex it's really easy to modularize your app into standalone, reusable components) and also have performance benefits, because they have better access to the graphics card, etc...

I'm not that sure. Please take a look on the following articles to see my point:
http://www.sitepen.com/blog/2010/01/19/commonjsjsgi-the-emerging-javascr...
http://www.sitepen.com/blog/2010/03/10/can-flash-thrive-going-forward/
http://www.sitepen.com/blog/2008/04/03/flash-silverlight-and-the-open-web/

It seems that rise of JavaScript server platform will hit both Flex and SilverLight.
Regarding performance of Flex I'm sure modern JavaScript library that running by modern browser have more advantages in this respect.

>PS. About the JSF team having very limited resources. At MyFaces we have something like 50 committers.

And you are one of them :)
Also I found out that you have a quite active blog.
I'm trying to say that you are in good position to promote the plan.
Only problem is that you still don't like it ;)

Thank you,
Vladimir

jkva
Offline
Joined: 2005-04-06

Well, to be honest, it's not that I don't like it. I hope I didn't express myself in such a way, since I usually try to delay those feelings until I get a solid understanding of the subject.

The issue is more that I don't yet understand it. I guess I need a more concrete example of the plan to understand it.

vladperl
Offline
Joined: 2004-08-11

> I usually try to delay those feelings until I get a solid understanding of the subject.

It's a great attitude. I embrace the same principle.

>The issue is more that I don't yet understand it. I guess I need a more concrete example of the plan to understand it.

Give me some time. I'm going on vacation during the next week and after that I will start fresh and produce something.

P.S.
I'm going to listen the following course in order to better handle the discussions :)
http://www.thegreatcourses.com/ttcx/coursedesclong2.aspx?cid=4294

jkva
Offline
Joined: 2005-04-06

Euhm, after reading this post, I can only think of one thing:
Why modify JSF if you really want to standardize GWT?

JSF has a specific architecture, design and programming model. At the moment, this works for some applications, for others it may be less appropriate (public internet, very high load, etc).

You're suggesting to change some of the most fundamental aspects of the framework: In your story, I see major changes to the component tree, state management, probably EL, remoting must be added, probably another view markup language (if any, Java might be better, like GWT), different event handling, an entire new standard component library and more.

When changing so much, why bother rewriting JSF while there's another framework that simply fits your suggestion better?

No offensive intended, but if your scenario becomes reality, I think everyone's better off with a brand new framework, instead of a retrofitted JSF. And personally, I prefer Flex/JavaFX/Silverlight over a 100% JavaScript solution (like GWT or your plan).

So -1 from me...

vladperl
Offline
Joined: 2004-08-11

jkva,
First of all I'm very thankful for your response.
Let's strictly logically take a look at your argumentation.

>Why modify JSF if you really want to standardize GWT?
Honestly I don't know much about GWT that why I went to their site and took a look.

Here is the first example I found there:
"final Button sendButton = new Button("Send");"
To me personally this example just show how far GWT is behind of JSF.
If I'm fighting here to remove rendering code completely from java components then what I can say about approach where content of UI described in Java code. It's just disaster to use in such manner java for web applications. As proof of my point read the following:

"What's New in GWT 2.0?
With UiBinder, GWT now allows you to create user interfaces declaratively in XML instead of having to assemble them programmatically. The XML file supports the following features to make your UI code smaller, more readable, easier to maintain, and faster to develop:

* Specify CSS styles locally, without having to worry about duplicate CSS names.
* Intermix GWT widgets with native HTML for faster, more efficient apps.
* Conveniently support bundled resources and internationalization."

Looks like they just moved to the stage JSF 1.2 :)
I would say why modify GWT if you really want to standardize JSF?

>You're suggesting to change some of the most fundamental aspects of the framework:
>In your story, I see major changes to the component tree, state management,
>probably EL, remoting must be added, probably another view markup language (if any,
>Java might be better, like GWT), different event handling, an entire new standard
>component library and more.
That's mostly is correct interpretation of my suggestions except for part related to markup language. Java language is not markup language by nature and frameworks who are trying to use Java as language describing user interface eventually will fail if they don't change the approach. Take for example Delphi they never used Pascal as language describing user interface. For this purpose they used specific markup.
Here is example:
object RequireMonitoringYes: TQRShape
Left = 709
Top = 512
Width = 12
Height = 12
Frame.Color = clBlack
Frame.DrawTop = False
Frame.DrawBottom = False
Frame.DrawLeft = False
Frame.DrawRight = False
Size.Values = (
31.750000000000000000
1875.895833333333000000
1354.666666666667000000
31.750000000000000000)
Pen.Width = 2
Shape = qrsRectangle
VertAdjust = 0
end

Regarding using different markup languages I suggest it because if all main architecture recommendations will be accepted it will be pretty easy to adapt additional markup languages. You could adapt any kind of markup languages. Good examples are bindows, JavaFX. With moving rendering functionality to client side no big problem to create migration path from Desktop applications such as javafx/swing to powerful JSF based applications. There is a real chance for JSF framework to become technologically superior framework. Only JSF has a chance to close the circle between desktop applications and web applications. More of that! There is a chance that JSF could become language agnostic. JSF already has support for Groovy. Kill rendering functionality on the server side and you will see how much power JSF will get.

>When changing so much, why bother rewriting JSF while there's another framework >that simply fits your suggestion better?
Two main reasons
1) There is no framework that has server and client side correctly balanced and implemented on high level.
2) Migration to another framework will take too much resources. Beside there is no guaranty that in future a new framework will be right choice.

>No offensive intended, but if your scenario becomes reality, I think everyone's better off with a brand new framework, instead of a retrofitted JSF.
For developers who already used JSF for years is the best choice - adapt JSF to new requirements.
I have migrate from JSF 1.2 to JSF 2.0 without much efforts even there was some significant changes. Also keep in mind that regular JSF developer will be able to continue working in the same manner that was before. After all nobody here is suggesting to deprecate facelets syntax or managed beans.

>And personally, I prefer Flex/JavaFX/Silverlight over a 100% JavaScript solution (like GWT or your plan).
If you are not component developer you don't have to use Javascript at all.
Even in situation when all UI components moved to client side you should able to work with Java. So I don't see much trouble to JSF developer.
Anyway they used to design UI with help of HTML template.
After all you could use Flex/JavaFX/Silverlight as VDL languages with JSF if the plan will be accepted.
In case I didn't change your mind please send me -1 again :)

-1: no
0: not sure
+1: yes

jkva
Offline
Joined: 2005-04-06

> ...
> If I'm fighting here to remove rendering code
> completely from java components then what I can say
> about approach where content of UI described in Java
> code. It's just disaster to use in such manner java
> for web applications. As proof of my point read the
> following:

JSF doesn't put any restriction on the way you write components. If you prefer JSP, FreeMarker or whatever, it can be implemented. Before 2.0, you always needed some Java, at least to bootstrap the rendering process, but since 2.0, you can even write components using only markup.

> Looks like they just moved to the stage JSF 1.2 :)
> I would say why modify GWT if you really want to
> standardize JSF?

You're talking about the programming model (@compile time). I was talking about the runtime characteristics. GWT compiles into JavaScript and has stateless server side services. JSF is a server side framework. That's a very fundamental difference. GWT uses a specific kind of remoting mechanism to let the client communicate with the server. JSF uses POST (or GET/"Ajax" since 2.0) for everything. This is very different. Where state management is implicit in an Ajax application (the state is in the DOM and the DOM is kept alive across requests), state management is one of the key features of JSF (and this is necessary, because it's a server side application).

> That's mostly is correct interpretation of my
> suggestions except for part related to markup
> language. Java language is not markup language by
> nature and frameworks who are trying to use Java as
...
> Regarding using different markup languages I suggest
> it because if all main architecture recommendations
> will be accepted it will be pretty easy to adapt
> additional markup languages. You could adapt any kind
> of markup languages. Good examples are bindows,
> JavaFX.

Maybe someone else can correct me here, but JSF is limited to markup that is rendered by the browser, like HTML. I think implementing a RenderKit for JavaFX is very difficult with the current framework, because it impacts almost all other parts of the framework. For example, if I understand your proposal correctly, phase 1, 2 and 6 can be removed. And I'm sure there are big implications on the other parts.

> With moving rendering functionality to client
> side no big problem to create migration path from
> Desktop applications such as javafx/swing to powerful
> JSF based applications. There is a real chance for
> JSF framework to become technologically superior
> framework. Only JSF has a chance to close the circle
> between desktop applications and web applications.
> More of that! There is a chance that JSF could become
> language agnostic. JSF already has support for
> Groovy. Kill rendering functionality on the server
> side and you will see how much power JSF will get.

I don't see the relation with Groovy. We already support Groovy, and at MyFaces, I hope we soon support Scala too. No need to move rendering to do this. Remember, all supported languages compile to Java bytecode.

> >When changing so much, why bother rewriting JSF
> while there's another framework >that simply fits
> your suggestion better?
> Two main reasons
> 1) There is no framework that has server and client
> side correctly balanced and implemented on high
> level.

But you're suggestion sounds to me like changing something well-balanced to something less-balanced.

> 2) Migration to another framework will take too much
> resources. Beside there is no guaranty that in future
> a new framework will be right choice.
>
> >No offensive intended, but if your scenario becomes
> reality, I think everyone's better off with a brand
> new framework, instead of a retrofitted JSF.
> For developers who already used JSF for years is the
> best choice - adapt JSF to new requirements.
> I have migrate from JSF 1.2 to JSF 2.0 without much
> efforts even there was some significant changes. Also
> keep in mind that regular JSF developer will be able
> to continue working in the same manner that was
> before. After all nobody here is suggesting to
> deprecate facelets syntax or managed beans.

So you're saying: Let's rewrite a very large portion of JSF 2 but keep the old stuff? This doesn't sound like a good idea to me. I also don't think the comparison with the 1.2-2.0 migration is valid, since 2.0 works the same as 1.2 if you used Facelets. You get some extras with 2.0, but your application still works fine without them. You can simply start using one feature at a time, for example starting with an event tag, adding some Ajax support and then migrating to bean validation, one page at a time.

I don't see this simple migration path in your strategy, because some of the fundaments are either removed or changed. As said, his didn't happen in 2.0.

>
> >And personally, I prefer Flex/JavaFX/Silverlight
> over a 100% JavaScript solution (like GWT or your
> plan).
> If you are not component developer you don't have to
> use Javascript at all.

My main concern regarding those rich clients is that they are more powerful than JavaScript will be. They have big advantages with the programming model (in Flex it's really easy to modularize your app into standalone, reusable components) and also have performance benefits, because they have better access to the graphics card, etc...

> Even in situation when all UI components moved to
> client side you should able to work with Java. So I
> don't see much trouble to JSF developer.
> Anyway they used to design UI with help of HTML
> template.
> After all you could use Flex/JavaFX/Silverlight as
> VDL languages with JSF if the plan will be accepted.

I think this is not a simple task with the current architecture.

> In case I didn't change your mind please send me -1
> again :)
>
> -1: no
> 0: not sure
> +1: yes

Sorry, still -1. It just doesn't look like JSF to me.

PS. About the JSF team having very limited resources. At MyFaces we have something like 50 committers. I don't know the size of the Mojarra team, but I think JSF is the biggest web framework for Java. JQuery, for example, is a one-man-project.

jkva
Offline
Joined: 2005-04-06

Hi vladperl,

Maybe it's a good idea to write a simple PoC. I currently see big issues, but I probably have this impression because we're talking about different things.

To make the plan more clear, I think a PoC is a good idea.

Regards,
Jan-Kees

vladperl
Offline
Joined: 2004-08-11

Jan-Kees,
>To make the plan more clear, I think a PoC is a good idea.

I had a weak hope that somebody will support ideas from beginning and even take responsibility to implement working prototype.
It's not happening yet so I'm going to start work on it myself.
In some respect your minus one helped more than plus one :)

Best regards,
Vladimir