Why does Sun come up with a jsf,jsf why it is this way, I think the reason is this.
First, component-based Web development will be a trend in the future. Self-contained components facilitate the processing of the IDE, which can improve development efficiency.
This means that JSF is superior to the MVC framework such as struts/webwork, because it can be combined with the IDE to generate code from the dynamic.
But the traditional pure hand-written MVC framework, has affected the development efficiency.
Because Java technology does not have an obvious advantage on the client side. Applets have been discarded and Java's strengths are on the server side. Sun can't run to use JavaScript because in the eyes of traditional developers, JS is only a trivial task.
So in the architecture they designed, all of the user events are placed on the server side to handle.
This decision creates a fatal flaw in JSF. It binds the event-handling model to the server, limiting the responsiveness of the interactive design. The consequent network latency destroys the usability of the software.
This is why Ajax is not fully functioning in the JSF architecture.
JSF design idea a bit imitate VB, component development This direction is correct, Ajax development will also take this road. But the biggest difference between JSF and VB is that the event model of VB is locally processed. This is a fundamental difference, so if JSF does want to imitate VB, it is also parody.
And in the design phase of JSF, synchronous requests/responses are mainstream, and their ideas are still firmly tied to the page-based development approach. Never thought of other possibilities at all.
Asynchronous request/Response is the biggest difference between Ajax and traditional development methods, and asynchronous brings better interaction design.
In the 1th chapter of Ajaxinaction, the author gives a convincing example. GoogleMaps when the user scrolls the map, gets the new map picture, because it is asynchronous request, therefore will not interrupt the user's operation flow.
And in the traditional map service, each scrolling may need to refresh the page.
Use Microsoft's Map service to feel the obvious gap, and it doesn't even allow users to scroll the map.
Http://terraserver.microsoft.com
I used to say that GoogleMaps is not Ajax, because there is no use of xmlhttprequest, so that seems to understand a little narrow.
GoogleMaps request a picture of the map, using the method of modifying the SRC attribute of the dynamically created IMG element so that the request does not interrupt the user's operation and therefore is asynchronous.
We see in ajaxinaction that the author uses GoogleMaps as an AJAX application, and in Pragmaticajax the author says GoogleMaps is not strictly Ajax, both of which make sense.
JSF can actually be better when combined with applets. Applets are multi-threaded and can capture user action events and are sent asynchronously to the server. This will not interrupt the user's operation.
But the architecture that was designed is complicated. And applets are things that have been decided to abandon.
JSF and Javawebstart can be combined, but JWS is designed to build a completely different Web application, richclient, rather than being designed to build RIA applications that run within browsers.
So JSF is only a transitional program, in the Ajax/flash competition has long been not in the scenery.
Future browser-based RIA Development, Ajax, Flash are two of the most promising technologies.
According to Zechin's judgment, it could be a three-point world, Ajax, Flash/flex/laszlo, and M$ Atlas.
Atlas is a kind of flash-like technology developed by m$, and is still just a vaporware, not seen.
Javawebstart By contrast can only be limited to a few internal applications.
There may be no Java location in the future for the presentation layer development at the client, which Sun does not want to see, but Sun is only a small player in the race.