English:
I post this ticket just after the release of a massive web app that extensively use Asynchronous request though javascript (i have a A, i have a J, maybe the other A and sometime the X, sometime the J or also the T). The main reasons were:
- To enhance the user experience.
- To avoid the connection lost between to page.
- And also, to please the client.
However some unexpected benefits emerge; in term of architecture and performance.
For the story , the concept of asynchronous request is not new (i consider the iframe as the first attempt) and the old flash dog will remember this wonderfull actionscript 1.1 function (2002 baby). But it came really popular around 2006 and the rise of the so-called web 2.0 and bring back javascript from the dead.
Anyway, in term of architecture, everybody agree on the fact that the best thing to do when you develop a web app is to split in distinct entities the stacks; That most of the people , do/call MVC pattern. So when to take the time to think about it, you realize that you can use some old school HTML page as view (no template engine or i-push-header-myself-in-the-http-request), your javascript code act as your controller (ndlr. grab asynchronously the data from the server and insert them in the page A.K. the view) and your server-side technology/db act as your model.
So if you already have developed any dynamic web page (a web app is in the approach not that different) you now see me coming.
What is the common data-flow ? "get what should be displayed"(controller) -> "get the proper data from the database" (model) -> fetch them into the view (controller) -> be read by the user (view). On the traditional approach this is all done by the server, the same that all your users connect to. So now imagine you have 2 users at the same time the previous flow is down 2 time and so on. Isn't lot to ask for a poor computer that even don't have a screen and is somewhere in a huge data center ?
When you can do "get what should be displayed"(controller) -> "get the proper data from the database" (model) -> fetch them into the view (controller) -> be read by the user (view) (red stand for process on the client side and orange on the server side).
You see, using AJAX i just free my server from 75% of the tasks, meaning i now have more resources to handle more users, meaning i won't need to buy a second box now and then save money for christmas :D. And to keep on the financial aspect, don't forget that a JSON(that is gziped in the HTTP request) at least 100 time smaller than a page or event the portion of the page that supposed to contain those data (HTML elements are then created dynamically on the client-side and not sent from the server to the client). So you also save bandwidth (A.K.A. money).
In conclusion, i would say that:
- AJAX is a sort a distributed programming, not in a grid but using your server and the user's machine.
- AJAX help you to save money (less stress on the server, less bandwidth).
- AJAX can help you in you architecture by keeping the logic and the presentation the hard way (we even can say physically).
So was is the downside of it ? It's javascript, or it would be better to say, the web browsers. It's literally each one have it's own implementation of JS. Of course syntax is the same, but the behaviors is so different, and you realize that the biggest part of the work is not to develop the feature, is to make it compatible with the various browsers.
You might ask: Do it worth it ? That's a good question :-)
P.S.: This article is directed toward web application and toward dynamic web contents. Use those technics for a web page is at your own risk of bad indexing.
Francais:
Ca viens
