Web Application Paradigm Specialization and JSF 2.0
In some ways, this blog could be considered my recap of 2007 and the mistakes and knowledge I've gained. In other ways this blog acts as a foundation for ways I'd like to view JSF 2.0.
When the AJAX gimmicks clear, we'll be left with two camps: the keep it simple page paradigm and then those who want the full rich client. Where people are getting bit right now, or possibly realize they will be, is when you sit in the gray area of the two camps. Right now, that's about everyone.
Let's talk technical first.
If you continue this route and keep layering in functionality with AJAX/JS as the solution, you'll end up with neither a rich client app nor an efficient web application.
We took this route and then ended up backing a bunch of it out because of performance issues. Don't get me wrong, we were by the book with all of the tricks and optimizations-- beyond the appeal of AJAX-- functionally, nothing was really gained that couldn't be rethought from a pure task flow standpoint.
Now lets get ridiculous and talk (best) case scenarios. You are using JSF-EXT or Flex to build your pages-- you still wouldn't kick the user into a different page [load] with mouse clicks would you? Even if you did have WPF or Firefox 8.0 with better performance and features, you must also serve the end user and clever uses of AJAX and JS behavior can sometimes be difficult to interact with. Either go simple click-to-page flows, or stay in familiar boundaries of the desktop paradigm.
The Role of JavaServer Faces 2.0
If we commit to saying there's only two paradigms in web application development and say that anything between will be covered by supplementing the two extreme use cases, then JSF 2.0 needs dramatic changes from JSF 1.2.
On one side, you have the traditional page paradigm. JSF works well in this solution, but comes at the cost of stateful management and processing overhead. In addition, JSF's actions are represented in POST requests, not efficiently handling the traditional GET/Restful actions which content-based sites follow.
On the other side of full rich UI clients, JSF works well here too, but to a point. It does a great job of setting up a screen of rich AJAX components, but when it comes to loading in new pieces dynamically or introducing a new tab of content, things start to fall apart as JSF's navigation structure is stuck in the page paradigm. In addition, the screens' state is retained in a singular whole, which forces you to load everything up front or run into discontinuities later.
You could say that JSF today sits in the gray area of solutions for web application paradigms. While this covers a large number of scenarios, it doesn't surprise me at all that a single development group may use multiple UI frameworks for their applications which are specialized to the two primary application paradigms. Example, using WebWork or Struts for your public application, but JSF or Flex for your internal maintenance/data applications.
What I'd like to see for Java EE 6
With JSF 2.0, I'd like to see a re-write of JSP and basically say tags are stateless components. Introduce annotations and reduce XML within JSP into a very efficient and handy templating solution on the web which can be used with other frameworks or with simple servlets. Then come in with JSF 2.0 and add in support for stateful components which work seemlessly with the stateless components-- introduce @Stateful or @Event concepts into the foundation of the new JSP presentation framework.
This easy to use JSP templating solution would more than solve the traditional page paradigm avenue while providing a foundation for rendering back service-based messages for rich clients. Simply put, low overhead, stateless, and compiled for performance.
Like icing on a cake, layering in JSF 2.0 features can then more easily scale with functionality in a highly optimized manner. If we approach this strategy of integration, developers can be much more flexible in the Java EE 6 platform in accomodating different use cases, even when we are mixing paradigms. Conceptually, developers work with one kind of component and no longer would there be multiple phases in view construction which consistently confuse developers.
The fundamental gain of JSF as your application controller is the idea of automatic composition and scalability of complexity. I've written about this before, but even in stateless component form, this architecture would be like declaratively wiring together 10 or 15 Struts Actions, reflective of your matching UI.
You may read the above and ask how is that any different than JSF 1.2 and JSP 2.1 today and the answer is simple-- JSP and JSF weren't originally written together and succeeding maintenance releases have too much legacy compatability issues to really deliver the simplicity developers expect today.