I love async, but I can't code like this

I personally share the original author's perspective on this and was disappointed to see more sophisticated methods of writing concurrent code (futures, coroutines, etc) dropped from Node in favor of raw callbacks. In my experience, chaining raw callbacks is too easy to get wrong for it to be considered a reliable way of writing all your asynchronous logic, even if it is a great primitive to build a framework on top of. In particular, the effort involved in propagating exceptions all the way through a callback chain is rather significant, and making a mistake in a single function undermines the reliability of the entire chain (usually resulting in work silently being dropped on the floor). I wish more of an effort was made to address this problem.

  The “await” operator used twice in 
  that method does not mean “this method now blocks
  the current thread until the asynchronous 
  operation returns”. That would be making 
  the asynchronous operation back into a
  synchronous operation, which is precisely
  what we are attempting to avoid. Rather, 
  it means the opposite of that; it means
  “if the task we are awaiting has
  not yet completed then sign up the rest of
  this method as the continuation of that task,
  and then return to your caller immediately; 
  the task will invoke the continuation when 
  it completes.”

    async void ArchiveDocuments(List<Url> urls)
    {
      Task archive = null;
      for(int i = 0; i < urls.Count; ++i)
      {
        var document = await FetchAsync(urls[i]);
        if (archive != null)
          await archive;
        archive = ArchiveAsync(document);
      }
    }

  _ =
    fileMenu: ->
      mainWindow.menu "File", (e,f) => this.onFile(e,f)

    onFile: (err,file) -> 
      if err then throw err
      file.openMenu (e,m) => this.onOpenMenu(e,m)

    onOpenMenu: (err,menu) ->
      if err then throw err
      menu.item "Open", (e,i) => this.onOpen(e,i)
  
    onOpen: (err,item) ->
      if err then throw err
      mainWindow.getChild type('Window'), (e,d) => this.onDialog(e,d)

    onDialog: (err,dialog) ->
      if err then throw err
      #...

  _.fileMenu()

The best solution would be to add monadic syntax to javascript. You would get CPS, coroutines, error propagation, early failure, and several other capabilities all using the same syntax. Shit like generators or coroutines are just ad-hoc special-cased versions.

    yield to.request("/feedback", "POST", (
        yield to.prompt("What are your impressions of async.js?")
    ));
    yield to.inform("Thanks for your feedback!");
    // do more stuff here

    async.prompt(
        ["What are your impressions of async.js?"],
        function (response) {
            async.request(
                ["feedback", "POST", response],
                function () {
                    async.inform(
                        ["Thanks for your feedback!"],
                        function () {
                            // do more stuff here
                        }
                    );
                }
            );
        }
    );

    var clickEvent = yield myButton.next("click");

Narrative JavaScript http://www.neilmix.com/narrativejs/doc/ has a single construct, the arrow which turns everything after the arrow into a closure which is passed as an argument.

StratifiedJS (http://www.neilmix.com/narrativejs/doc/) is more rich with a number of new keywords: hold, spawn, wait etc. for asynchronous programming.

http://news.ycombinator.com/item?id=1549023

The 'nested callback' problem is one I've encountered over and over. I've figured out a relatively nice way to work around it. The solution goes something like this.

- Take the individual actions that you want and put them in closures.

- These closures take 1 argument, which is always a callback function that takes no arguments (this is the convention you structure everything around)

- Put these closures in an array, in the order that you want them executed

- Pass the array to a function that executes them for you (in Haskell it's called a sequence)

I have a really quick and really dirty presentation about it here, http://www.moondust.dds.nl/text/async-presentation/

Some code on github up here, https://github.com/michiel/asynchelper-js - the sequencer.js function is verbose, if you read the next SO link I've included a three line example of implementing it.

And a stackoverflow answer using this code and some explanation here, http://stackoverflow.com/questions/4462605/jquery-ajax-each-...

And another one as a gist on github here, https://gist.github.com/604730 (for rendering a massive table from JSON data).

There's a lot more to this sequencer pattern. You can nest sequences, you can have the sequencer run each callback using setTimeout(callback, 0) to release control back to the main loop and get out of 'script is doing too much' popups, etc.

Need to make an async call? Make a closure that performs the async call and invoke the callback argument in your async callback.

Need to add some random JS code to a sequence? Wrap it in a closure and call the callback when you're done. If the random JS code requires an async call, see the previous paragraph.

Error handling, of course, is still awful. You can extend the sequencer convention to add error closures as a second parameter, you can do everything inside the closures in try/catch blocks and finally always call the callback, etc. But that just tends to make a mess of things. So the examples just assume everything is going fine.

It's not an ideal solution, but it's native JS and works everywhere.

It allows you to structure your code into functional blocks and work on them separately instead of making everything one big nested callback mess.

Just wanted to add a pointer to what I ended up using: https://github.com/sam-mccall/ship

It's lets you create pseudo-threads, you pretend you're calling a sync function, and get a promise back, which you can call methods on (giving more promises) etc.

It needs a rewrite to allow objects in different pseudo-threads to interact - i.e. the threads to cross. Currently it's just a queue of actions to perform which doesn't allow this.

I really can't understand why anyone would want to use anything else for concurrent programming.

   doSomething = (c) ->
      async.waterfall [
         (c) -> mainWindow.menu "File", c
         (file, c) -> file.openMenu c
         (menu, c) -> menu.item "Open", c
         (item, c) -> item.click c
         (c) -> mainWindow.getChild type("Window"), c
         (dialog, c) -> dialog.doSomething c null
      ]

Agressive source transformation becomes less of an issue.

Until a standard model of async emerges I think programming large web apps on node will feel a little like hiking with a stone in your shoe.

Just take python, ruby or php, and make JS on the server on par with them. Forget about creating servers, async stuff and coroutines, 90% of moms and pops websites don't need them.

There is a huge momentum behind SSJS but it is all being wasted waiting for node to be the mother of all js apps. It will never be.

I encourage you to check out http://news.ycombinator.com/item?id=2101789 ... with those functions javascript will be pleasant again.

It could work similar to the async monad in F#:

#asnc x = () -> var f = window.menu("file"); var m = f.openmenu(); m.click();

would unwind as:

window.menu("file",function(f) { f.open(function(m) { m.click(); }); });

  let async_copy (in:Stream) (out:Stream) =     asnyc {
      let buf = Array.create 8192
      let rec copy = async {
          return! match in.ReadAsync(0,buf.Length,buf) with
                  | 0 -> ()
                  | x -> do! out.WriteAsnyc(0,x,buf); 
                         return! copy; }
      return! copy; }

  let sync_copy (in:Stream) (out:Stream) = 
      let buf = Array.create 8192
      let rec copy = 
         match in.Read(0,buf.Length,buf) with
         | 0 -> ()
         | x -> out.Write(0,x,buf); 
                copy    
      copy