Planning Ahead: the Async Javascript Problem

Yesterday I posted about spaghetti-free Javascript code. A lot of reactions followed.

As it turns out, most people misunderstood my point. That’s probably my fault. Here is at again, more concisely:

When you write Javascript you have to think ahead: in the code I’m about to write, is there going to be an asynchronous call at some point? If not, I can write Javascript in a nice, synchronous succinct style. If so, in many cases I cannot really use many of the regular language Javascript constructs, such as for-loops, but instead have to use one of the many Javascript libraries that implement asynchronous versions of loops, conditionals, etc.

If, like in my example, you do not plan ahead — and it turns out you need an asynchronous call somewhere, you have to go back and rewrite a lot of your code to use the asynchronous programming style.

The three tools I listed are ways around this problem. There you can keep writing your code in a synchronous style, no matter if you need an async call at some point.

Hope that clears things up.

Tags: ,

This entry was posted on Thursday, March 3rd, 2011 at 10:18 by Zef You can follow any comments to this entry through the RSS 2.0 feed.

  • Pingback: Three Routes to Spaghetti-Free Javascript « I am Zef

  • http://twitter.com/meinte37 Meinte Boersma

    Keep up the good work, Zef!

    I’m a little disgusted by many of the reactions’ tone along the lines of “”… Obviously, this guy doesn’t know what he’s talking about!”. In some countries that’s called an Ad Hominem and has nothing to do with acting like an informed adult.

    This guy’s actually building something (it’s called mobl) which is useful, as opposed to pouring some bile onto another person’s blog. You could try and be constructive in the comments…

  • Iamnoah

    “If, like in my example, you do not plan ahead”

    Lack of planning leads to bad code… I’m not really sure why you’re advocating a lack of planning?

  • http://sgoguen.myopenid.com/ Steve Goguen

    Nice article. I recently solved my async problems by writing a light-weight library that resembles JavaScript Arrows (http://www.cs.umd.edu/~jfoster/papers/cs-tr-4923.pdf) and the Rx-JS (http://msdn.microsoft.com/en-us/devlabs/ee794896) library.

    What I’m wondering is, as long as you’re writing your own languages/dialects, why not introduce a nice syntax for monadic binding so users can write their own monadic implementations?

  • http://zef.me Zef Hemel

    I’m advocating abstracting from irrelevant details, such as whether I’m going to need an asynchronous call at some point.

  • http://zef.me Zef Hemel

    Because people don’t understand monads?

  • http://aplatypus.myopenid.com/ Will

    Thanks for those links Steve. I’m still digesting, however I am lucky enough to have a background in mult-threaded, asynchronous coding across several architectures from spanning real-time, clustered processors and light-weight threading. You’re right we ought to look for a better model. At the current state of the industry, they are behind the curve on the state-of the prior-art largely because some good solutions were deprecated in favour of simpler alternatives like the ‘Windows message loop’ and the really nice handling on GUI-s like KDE and GNOME, etc.

    One day, I’m thinking someone will come-up with a similar simplification for multi-threaded (async) applications like the one PARC invented for GUI-s.

  • Will

    My thought was that you were advocating making planning simpler by using one of these solutions, not simply avoiding planning. Is that a correct characterization?