Q: What is the AJAX?
Q: How does the AJAX work?
A: The AJAX works as follows:
- the XmlHttpRequest connects to the server and a server-side component handles the request,
Q: So, why do we need AJAX?
A: To minimize the ugly effect of page reloading? No. It can be achieved much easier.
There are in fact two important reasons for AJAX:
- to minimize the amount of data sent to and from the application server (we do not POST the entire HTML form and do not respond with the entire HTML page)
- to improve the user performance (for example: to provide a dynamic context-sensitive content when the user types into a textbox)
Q: Why do we need AJAX frameworks?
A: It is easy and possible to write an AJAX-style application without any support from a high-level framework. You just learn how to use the XMLHttpRequest and are on your own.
This, however, could be very inefficient. For any action which needs to be "AJAXified" you need three core components:
- (S) any server-side component which handles the GET/POST of the request from previous step
I call these three components I, S and R (Init, Server and Response) and I call the whole AJAX mayhem "the I-S-R problem".
The nice aspect of calling all these three components is to realize that they are, in fact, quite independent. You can expect frameworks which attack all three issues in one coherent way, however nothing stops you from using completely different components for each of the three.
Q: I am lost in the plethora of AJAX frameworks. Can they be somehow classified?
A: I did some research and I've found the I-S-R perspective quite handy. When I see a new framework, I immediately focus on its I-S-R components and thus I am able to compare the framework to other which focus on similar issues. I think that five different approaches to AJAX can be identified:
I Incomplete I-S-R frameworks
- TIBCO General Interface
- ... many, many others
- you manually program the client-side user interface ...
- ... or manually program the server-side components ...
- ... or manually consume server responses on the client-side
- sometimes semi-automatic creation of callbacks (for example: server-side interface is "mirrored" on the client side by a set of proxy interfaces and a convenient way of calling server-side API with these proxies is provided)
None of these "incomplete" frameworks provide the complete way to handle the I-S-R problem. The interesting thing is that this is where you can mix different frameworks which operate on different levels of the problem so for example you can use Bindows as the GUI provider and the JayRock as the server-side gateway.
II Custom AJAX components
- someone builds a set of ASP.NET components which, instead of providing values for standard form POSTs, handle their events in an AJAX-style. Usually these components "mimic" the ASP.NET components and you "switch" from ASP.NET library components to such AJAX-enabled components by just changing <asp:Button> to <XYZ:Button> etc.
- it's great to see that someone knows how AJAX works, however I belive that "component switching" is just a wrong direction
III Ajax Managers
- you get an AJAX Manager, an ASP.NET component which, when put on a page, automatically converts all postbacks to callbacks. Sometimes it takes 15 seconds to AJAX-enable your application,
- more advanced frameworks are in the II and III group in the same time - you have AJAX Managers which convert existing applications into AJAX-enabled applications plus a bunch of optimized components is available for more advanced UI stuff
IV "Client-side logic with server-side tools" frameworks
- it sounds great until you try write a code which opens a file ...
- ... and then you realize that, in fact, you are using a really small subset of server-side technology and "opening files" does not belong to this subset ...
- ... so whenever you are to perform a server-side action, you are on your own (which means: use a framework which makes RPC possible, perhaps something from group I?)
V Server-side AJAX
- "dumb client, almighty-server", there's no "logic" on the client-side but rather messages passed to and from the server
- it is the server which holds the complete state of the application and the user interface and the client-side only renders it
- all client-side events are processed on the server
- this approach is the most resource demanding of all
- in the same time, it's most safe, since many typical internet attacks just don't work here (for example, Cross-site Request Forgery or ViewState Tamplering attacks are impossible).
- it's impossible to easily AJAX-enable existing ASP.NET applications with this approach
For an up-to-date list of .NET Ajax Frameworks, visit the AjaxProjects page.
Q: Any concise AJAX references?