Friday, September 15th, 2006

Eliminating async Javascript callbacks by preprocessing

Category: Programming, Toolkit, XmlHttpRequest

According to Harry Fuecks in this post on the SitePoint PHP blog, using Ajax should be easier:

The Catch 22 of AJAX is, for the sake of an easy life, most of the time we want to write “synchronous code” but asynchronous is the only way to avoid some rather nasty usability issues. This means rather than being able to write simple code, as we’d like to. We’re required instead to handle this via callbacks, but that’s now introduced a whole load more potential issues.

These issues he mentions include requiring a global XMLHttpRequest object to be available and handling multiple calls to a javascript function (like if the user gets a little too impatient). To help combat these issues, Harry recommends a two projects out there that have the functionality to make life a little bit simpler:

Posted by Chris Cornutt at 8:26 am

3.1 rating from 51 votes


Comments feed TrackBack URI

This seems like way way way overkill just to get the ajax issues undercontrol. Who though hmmm recompiling every js file i use is a greate idea??? Why not just use a framework that incorps the seemingly easy delay method into it… is it hard to right a while loop???

Comment by Mario — September 15, 2006

as i write ‘right’ instead of ‘write’ heheh i crack myself up 8P

Comment by Mario — September 15, 2006

Well if the while loop is wrong, you better right it :-)

Comment by Ryan Gahl — September 15, 2006

Hmmmm, interesting… I just ran into that problem the other day and I tried to do just what the person above suggests. Basically I had a variable tracking if a response had been received, and a while loop going as long as that variable was set to false. Problem was, the page would kind of hang, and a request that would normally come back quickly (hell, I was working on localhost!) would take a little while to process. Curious to see what these folks have done, although a quick glance at jwacs is a bit discouraging. The simplest of code meant to just fetch a page results in something like 600 lines of compiled javascript. Seems like overkill.

Comment by Thomas Messier — September 15, 2006

It’s definitely true that jwacs produces unreasonably large compiled output at the moment. That’s part of why it’s still in alpha. :)

Later versions will do a much better job of optimizing the size of the output, or so I hope at any rate.

Running a busy loop as you wait is a good way to burn a lot of CPU. Thomas, I bet your request was coming back slowly precisely because the server was on localhost. The busy loop was pegging the CPU and so the server had trouble responding. (At least, that’s what happened to me when I tried it).

Comment by James Wright — September 15, 2006

What about those Dojo Deferred stuff lately? Isn’t designed for stuff like this (synchronizing async’d stuff)?

Comment by toni — September 15, 2006

There is no “seemingly easy” solution to having code block for AJAX calls. You can use synchronous AJAX (one of the parameters in a XHR call) and it locks up the browser while it is waiting. Using a while loop produces the same effect, it locks everything up while waiting for the XHR to return (and takes cpu cycles as well). Unless you don’t mind locking up people’s browsers, it is absolutely necessary to maintain asynchronousness in your AJAX calls. The complication of doing callbacks to do this grows as you nest your function calls that have AJAX endpoints.
DOJO doesn’t have it figured out either. They have to resort synchronous (browser lock-up) to load deferred JS scripts. Alex has some clever techniques for packaging JS files to minimize the effects, but when data script data is needed, there is still lock ups.
Compiling/preprocessing JS may seem like a bad solution to some, but in terms of creating a simpler code flow and moving towards JS as more comprehensive development platform while maintaining proper browser behavior, I believe it well worth it.
I have been using Narrative JS for a while now (I believe that Chris Double and I are the two biggest users) and it has been wonderful for my project. There is been a lot of thought by a lot of people on the the AJAX synchronization issue, and Neil’s work has been a great contribution to this issue. If you want to see my project it is at
I think Chris is blogging about his work at:

Comment by Kris Zyp — September 16, 2006

Seems a weird point to make. Callbacks are how modular programming gets done. If you exclude that concept from what Harry calls “simple code”, you get badly written programs that get thrown away.

People will come around. A few years ago “simple code” probably excluded anything in javascript for many folks.

Comment by Trav — September 16, 2006

Thanks for that clarification James, that makes plenty of sense. I’ll have to upload the code to another server and judge on the performance. I’ll also be curious to study the jwacs code and see what it’s up to when I get a chance, although unfortunately I have precious little time lately…

Comment by Thomas Messier — September 16, 2006

“It’s definitely true that jwacs produces unreasonably large compiled output at the moment. That’s part of why it’s still in alpha.

Later versions will do a much better job of optimizing the size of the output, or so I hope at any rate.”

I never thought of that really that way.
Gotta go anyway my dog s asking to go for the daily walk…see ya bud!

Comment by Friendly Puppy dogs — October 6, 2007

Leave a comment

You must be logged in to post a comment.