April 20, 2006
@ 06:10 PM

Tim Bray has a post entitled The Cost of AJAX where he writes

James Governor relays a question that sounds important but I think is actively dangerous: do AJAX apps present more of a server-side load? The question is dangerous because it’s meaningless and unanswerable. Your typical Web page will, in the process of loading, call back to the server for a bunch of stylesheets and graphics and scripts and so on: for example, this ongoing page calls out to three different graphics, one stylesheet, and one JavaScript file. It also has one “AJAXy” XMLHttpRequest call. From the server’s point of view, those are all just requests to dereference one URI or another. In the case of ongoing, the AJAX request is for a static file less than 200 bytes in size (i.e. cheap). On the other hand, it could have been for something that required a complex outer join on two ten-million-row tables (i.e. very expensive). And one of the virtues of the Web Architecture is that it hides those differences, the “U” in URI stands for “Uniform”, it’s a Uniform interface to a resource on the Web that could be, well, anything. So saying “AJAX is expensive” (or that it’s cheap) is like saying “A mountain bike is slower than a battle tank” (or that it’s faster). The truth depends on what you’re doing with it. 

In general I agree with Tim that the answers to questions like "is technology X slower than technology Y" depends on context. The classic example is that it makes little sense arguing about the speed of the programming language if an application is data bound and has to read a lot of stuff off the disk. However when it comes to AJAX, I think that in general there is usually more load put on servers due to the user interface metaphors AJAX encourages. Specifically, AJAX enables developers to build user interfaces that allow the user to initiate multiple requests at once where only one requests could have been made in the traditional HTML model. For example, if you have a UI that makes an asynchronous request every time a user performs a click to drill down on some data (e.g. view comments on a blog post, tags on a link, etc) where it used to transition the user to another page then it is more likely that you will have an increased number of requests to the server in the AJAX version of your site. Some of the guys working on Windows Live have figured that out the hard way. :)


 

Thursday, April 20, 2006 8:01:51 PM (GMT Daylight Time, UTC+01:00)
"if you have a UI that makes an asynchronous request every time a user performs a click to drill down on some data ... where it used to transition the user to another page then it is more likely that you will have an increased number of requests to the server in the AJAX version"

That doesn't make a lot of sense to me. In that example you're just replacing one request with another.

Click in AJAX => AJAX HTTP request retrieves data
Traditional click => HTTP request for new page of data

So, I don't see how your example illustrates the fact that you'd make more requests (in fact you'd get fewer requests because you're not re-requesting images or other static elements of the page).

From what I've read of the discussion, it seems like the examples are based on people lazily using AJAX to do stuff that they used to do fully client-side with DHTML and pre-loaded, hidden, objects (for example, your blogroll to the right). That's a problem that people probably shouldn't be using AJAX to solve in most cases.
Thursday, April 20, 2006 8:47:41 PM (GMT Daylight Time, UTC+01:00)
Tom
>So, I don't see how your example illustrates the fact that you'd make more requests (in fact you'd get fewer requests because you're not re-requesting images or other static elements of the page).

The pages and images are usually cached by the browser so that doesn't count. The point is that your peak number of simultaneous connections goes up because a user can initiate more connection attempts in a given time period than before. It seems you are focusing on total number of connections/requests which shouldn't increase significantly depending on your design.
Thursday, April 20, 2006 11:55:48 PM (GMT Daylight Time, UTC+01:00)
That makes sense to me. Since the UI is more responsive, the user can accomplish tasks faster than before. That's a net benefit in UI improvement, but comes at a cost of higher number of requests per second.

You can't get something for nothing.

Of course, that can be ameliorated by focusing on prefetching data to the client etc... so that there's a bit more parity in # requests per click.
Sunday, April 23, 2006 2:11:14 PM (GMT Daylight Time, UTC+01:00)
Full ack to haacked.
You can't get something for nothing.

For some time i used every AJAX feature i could code together, but nowadays my server hosts several domains and every additional percent load average makes me cry.

Every person has to make its own decision.
Comments are closed.