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.

Got something to say?
  1. 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…

  2. Iamnoah says:

    “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?

  3. Steve Goguen says:

    Nice article. I recently solved my async problems by writing a light-weight library that resembles JavaScript Arrows ( and the Rx-JS ( 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?

  4. Zef Hemel says:

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

  5. Zef Hemel says:

    Because people don’t understand monads?

  6. Will says:

    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.

  7. Will says:

    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?

Trackbacks for this post

  1. Three Routes to Spaghetti-Free Javascript « I am Zef

Comments are closed now.