This chart has been drawn up to give an idea about what you stand to gain from applying Ajaxium as compared with the traditional AJAX approach.
AJAX |
Ajaxium |
| Developer skills required |
| In addition to skills in ASP.NET, Javascript, DHTML/DOM, AJAX framework use, knowledge base of different browser-dependent issues and bugs is required. |
Minimal skills that require some knowledge of ASP.NET and one page of the Ajaxium tutorial. |
| Developer productivity |
| Less than ASP.NET, Developers have to focus not only on ASP.NET programming, but also on client-side programming, including Javascript, DHTML, DOM and browser-specific bugs. |
Exactly the same as for traditional ASP.NET. The developer focus is only on the server-side programming. |
| Project extensibility |
| If new features are to be added, a lot of server- and client-side codes should be modified accordingly. It makes the extension job time- and labor-consuming. |
Exactly the same as for traditional ASP.NET. Developers can add/remove controls, change data binding rules, modify page content, and add/remove pages without thinking of underlying magic. |
| Refactoring |
| Fraught with difficulties as it requires modifying both the server- and client-side codes and subsequent browser compatibility testing right from scratch. |
As easy as for traditional ASP.NET. Developers work only with the server-side code. |
| Programming model |
| Two parallel but independent frameworks are used. One is the ASP.NET server-side code. The other is the client-side code, which accesses the server side-code and presents results in the browser. As a result, it is easy to fall into one of those sync nightmares when the client state fails to reflect the server state. |
Efficient ASP.NET programming model support. Developers work with the server-side code only. Designers can modify aspx files, control skins and do other operations without any effect on the code. |
| Relations between UI and business logic |
| The client-side code is a mix of UI logic and parts of the business code. This "code noodle soup" often creates debugging problems. |
The code is separated from the UI logic. Skins, controls inheritance, most of the 3rd party and custom controls can be used without any effect on the business logic. |
| ASP.NET designer support |
| Visual Studio Designer doesn't run Javascript, so designer support is very poor. No control will be visible if added dynamically to the page. |
Full ASP.NET designer support. You manipulate controls as you wish. |
| Debugging |
| Fraught with difficulties in view of occurrence of visible problems in the server/client-side code or due to a difference between client and server states. |
Developers are to debug only the server-side code. Ajaxium can be disabled at any time to return to classic ASP.NET. |
| Use of custom and 3rd party controls |
| Inconvenience in using controls which belong to different frameworks within one project. |
Developers can use all ASP.NET controls available. Although incompatibility issues can occur if 3rd party control has some built-in AJAX features, there are lots of ways to get them eliminated. |
| Data binding |
| Developers are to implement something with similar functionality. |
Developers can use all of ASP.NET data binding features. |
| Return to ASP.NET |
| Great efforts must be taken to return from the AJAX programming model to classic ASP.NET. If both AJAX and classic versions of the same Website are to be developed and AJAX is used intensively, developers virtually have to work with totally separate projects. |
Switching between Ajaxium and classic ASP.NET is possible even at runtime. It is possible to turn Ajaxium off for only specific sessions on both client and server sides. Switching back is performed automatically if the visitor's browser lacks Javascript or XmlHttp support. |
| Browser compatibility |
| Developers have to manually detect and fix all incompatibility issues. |
All ASP.NET-supported browsers are supported by Ajaxium. In the event of any fatal incompatibility (for example, XmlHttp object is not accessible), Ajaxium gracefully falls back to classic ASP.NET. Same occurs when the visitor's browser has Javascript disabled. |
| Search engines support |
| Most of search engines completely ignore all Javascript actions, and are totally unable to index the content of the AJAX application. |
Ajaxium views a web crawler as a browser with no Javascript support, and automatically and gracefully degrades back to standard web pages. |
| Server-side CPU load |
| Implementation of parts of the business logic on the client may sometimes lead to a decrease in the CPU load. |
Server CPU load will somewhat increase in comparison with classic ASP.NET since additional processing of the page content is required. |
| Page updates efficiency |
| Efficiency depends on the scope of efforts taken. When most of the business logic is implemented on the client side it can be very effective. |
Efficiency depends on changes between page states. Automatic optimization is performed by Ajaxium to detect page changes and perform updates accordingly. If required, additional optimizations can be carried out by developers to increase efficiency. |
| Client-side performance |
| Depends on the amount of code working on the client side and the scope of efforts taken during coding. Usually the client's CPU load increases and the overall performance improves because page updates are performed by Javascript. |
Depends on the amount of changes between the displayed state and the state received from the server. Visible performance improves in comparison to the full-page refresh during postbacks. Switching to classic ASP.NET can be done if the visitor has a very slow PC (for example p100). |
| Traffic |
| Can be very small, but again it depends only on the scope of efforts taken. |
Automatically optimized by Ajaxium. Depends on the changes between the displayed page and the state received from the server. |
