Ajax
There have been two distinct approaches to AJAX application development in recent years, each of which extends the previous structure model. Because the nature of the two methods looks different, one should be selected in the development of the actual application.
When we first heard the term Ajax, our first reaction was probably its high web page interactivity. Some of the necessary code for Web applications in JavaScript, at least, provides interactivity, although there is a consensus on the meaning of AJAX applications, but there are some differences as to how developers interact with JavaScript or how to distribute display logic between client and server.
In recent months, several Java-centric rich-client frameworks have been reported in Artima to completely hide the developer's interaction with JavaScript. These frameworks integrate JavaScript into the JSF components as a tool for processing JavaScript, and the details are hidden from developers. Leveraging the advantages of the JSF server-side performance model, JSF based on Ajax presents the state of the component on the client.
Instead, Ajax has an advantage in individual client component toolkits, such as dojo or prototype, that not only renders JavaScript to the user, but it is easier for developers to develop page type applications. For example, the Dojo Toolkit provides a number of APIs that simulate an important part of the J2SE API, such as a collection and validator. In addition, UI tools, such applications will not only play a role in displaying logic, even some business logic on the client, these business logic will be encoded using JavaScript. Interacting with the server side will be limited to the fact that the client application must interact with external resources, such as extracting the data to the client or saving the user's changes to the data.
Because the Ajax-based JSF approach performs on the server-side presentation layer and blends AJAX features into components, it looks like an extension of thin clients and is a direct derivation of traditional Web applications, and the subtle common denominator of this approach is the Sun Ray thin client device, This thin client device displays desktop pictures on the server side, and the client handles at most one dedicated display. The second approach is a client-server extension that displays the logic of the application between the client and the server. In Ajax, the client is a programmable Web browser.
Both of these offences are based on good practice, different systems in application development, thin clients are involved in the incompatibility of JavaScript execution in browsers, and they rarely relate to whether the thin client model is preferred even if all browsers are good at displaying JavaScript.
However, JavaScript is still more difficult to develop logically, in a new version, EcmaScript 4, which provides a complete object-oriented language, because it is fairly standard and browser execution will be compatible. In addition, the client class library has also masked most of the incompatibility of browsers.
Client proponents believe their approach is better able to use local computer resources, which can also lead to the substitution of traditional desktop applications in the application. Even without a persistent network connection.
Experienced that each method has its pros and cons, if you develop a new rich client application, you have to choose either a thin client or a client-server model.