As a long time Java developer and more recently a JSF enthusiast I have been pondering the future direction (and viability) of JSF 2.0. The first question is why I listed JSF with AJAX, FLEX, and XAML, it’s because I’m biased, so bear with me. First let’s focus on AJAX, FLEX, and XAML.
HTML has proven to be a robust information delivery platform but what is changing is how we build and deliver applications. Information delivery (mainly static) is different from Application delivery (mainly interactive) and the next generation internet applications need a more robust interface than HTML can provide. I liken this to the old days where HTML is Dos, FLEX is Macintosh, XAML is Windows and AJAX is Dos wrapped in a UI framework.
The new game is to run a high end UI subsystem in-side a virtual machine executing within the browser. Having experienced the last UI war and looking at the landscape, I would currently place money on XAML. Let’s face it the rules are changing. Anyone trying to hang on to HTML as an application markup language and UI engine will be out to pasture in 5 years.
With XAML Microsoft will have changed the game by moving both code and the UI presentation framework back to the client desktop right on top of their Windows operating system. .NET developers will have 15 years of API’s, tools, capabilities at their fingertips.
FLEX has recently gained a lot of mindshare. Its biggest advantage is that it has a robust UI presentation framework that can on a mature UI engine that executes well within a large number of desktop browsers. It provides a superior look & feel over most AJAX + HTML solutions but also shares many of the limitations of AJAX. The largest limitation is that Actionscript must be used to enable client side functionality and it does little to solve the larger (server-side) issues of building applications.
What I have always liked about JSF that it is a component based model focused on building applications. JSF 1.X is well suited to building HTML applications and yes, extended with AJAX, is capable of building rich internet applications. The problem I have with all this is that JSF 2.0 is kind-of hitching itself to AJAX which I think is a dead end.
To all of the above I ask the question what happened to Swing. I think Swing can compete well with XAML. It has been long proven that Swing can be represented with a mark-up language. Just take a look at Thinlet, SwiXML, CookXML, etc. Java has its VM, XAML has CLR, the differences will be only important to language enthusiasts. So here is where we are left.
JavaServer Faces currently takes care of server-side (as name implies) application delivery but does nothing to address client-side application delivery or the evolving direction of the rich internet application. JSF 2.0 needs to expand to cover client-side processing or superseded with something else; I call this JavaClient Faces (JCF). We can still stick with different client side render kits but certainly Swing and/or SWT should be an initial offering. We should be able to write code so that we can bind to either client or server side attributes and/or methods.
Here is where many of the new frameworks run into trouble. I still think there is a need for Server Side processing. I really don’t think that client desktops should be executing business logic or making direct web service calls for data. The processing on the client should be for look & feel effects, handling simple user interactions, validations, and conversions. Business logic should still remain on the server.
We should be able to expect that our java code will be partitioned to run either on the client or the server, depending on how we want to implement things. This java code will be automatically packaged and downloaded to the client.
I think this should be the direction of JSF 2.X, I could elaborate more, but wanted feedback from the community.