Several reasons why Ajax is better than JSF

Why does Sun make a JSF, and why does JSF look like this? I think the reason is: first, component-based Web development will be a trend in the future. Self-contained components facilitate ide processing and improve development efficiency.

That is to say, the advantage of JSF over struts/webwork MVC framework is that it can be combined with IDE to automatically generateCode. The traditional manual MVC framework affects the development efficiency. Because Java technology has no obvious advantages in the client. The applet has been discarded, and Java's strength lies in the server. Sun cannot go to use JavaScript, because in the eyes of traditional developers, JS is only configured with a little trivial task.

Therefore, in the architecture they designed, all user events were handled on the server side, which resulted in the fatal defect of JSF. It binds the event processing model to the server and limits the responsive interaction design. The resulting network latency will destroy the software availability. This is why Ajax cannot fully play its role in the JSF architecture.

The design idea of JSF is somewhat similar to VB. componentized development is correct, and Ajax development will take this path in the future. However, the biggest difference between JSF and VB is that the event model of VB is processed locally. This is an essential difference, so if JSF really wants to imitate VB, it is also an effective solution. In addition, in the JSF design phase, synchronous requests/responses are the mainstream, and their ideas are still firmly tied to the page-based development method. I have never thought about other possibilities.

Asynchronous requests/responses are the biggest difference between Ajax and traditional development methods. Asynchronization.

In googlemaps, when a user scrolls a map and obtains a new map image, the operation process is not interrupted because the request is asynchronous. In the traditional map service, you may need to refresh the page every time you scroll. By using Microsoft's map service, you can see the obvious gap. It even does not allow users to scroll through the map.

Previously, I said that googlemaps is not Ajax, because XMLHttpRequest is not used. In this case, it seems that the understanding is narrow. Google Maps requests the map image by modifying the src attribute of the dynamically created IMG element. Such a request does not interrupt user operations, so it is asynchronous. In ajaxinaction, we can see that the author regards googlemaps as an Ajax application. In pragmaticajax, the author said that googlemaps is not a strictly Ajax application. Both of them make sense.

In fact, if JSF is combined with applet, it may be better. The applet is multi-threaded and can capture user operation events and send them to the server asynchronously. In this way, user operations will not be interrupted. However, this architecture is complicated. In addition, the applet is something that has been decided to discard. JSF and javawebstart can also be combined. However, JWS is designed to build a completely different type of Web application, namely, richclient, instead of being designed to build Ria applications running within the browser. Therefore, JSF is only a transitional solution at most, and the competition between Ajax and flash is far from good.

In the future browser-based RIA development, Ajax and Flash are two of the most promising technologies.

According to zexin's judgment, Ajax, Flash/flex/Laszlo, and Atlas of M $ may be used in three different parts of the world. Atlas is a technology developed by M $, similar to flash. Currently, it is only a vaporware and has not seen its true nature. Compared with Java WebStart, Java WebStart can only be confined to some internal applications.