Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sane Async Patterns in JavaScript

slideshare.net

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Sane Async Patterns in JavaScript

#21

Post by craigyk »

dap wrote: post #2

It's an interesting presentation, but it neglects an obvious solution to the nested callbacks problem, which are the various "async"-like control-flow libraries out there. More importantly, it neglects a critical problem with all of these approaches, which is being able to observe asynchronous state (from a debugger, repl, or whatever) when things go wrong -- when a callback (or event) you expected doesn't fire, or t…

Agreed. I think I saw that async in C# has exceptions that behave as one naively expects they should. That would make JS so much more awesome, even with callbacks. The worst part of them isn't the pyramid, IMO, so much as they all the horrible repeated "if error...."

Re: Sane Async Patterns in JavaScript

#24

Post by vec »

skylan_q wrote: post #7

While looking through the slides, I was wondering: Is there some community-standard way of naming/declaring a JS function to let the programmer know just by reading the function's name that it will return a promise instead of a final computed value? I'm interested in knowing how people handle this. It's easy to forget that a function doesn't return a promise if the function name makes no mention of it, so I just make…

I'm getting in the habit of letting the caller decide, something like the following:

    myAsyncFunc = function (param1, param2, callback) {
      var usingPromises = (callback === undefined);
      var returnVal = usingPromises ? Q.defer() : this;

      someFunction(function (err, res) {
        if (usingPromises) {
          err ? returnVal.reject(err) : returnVal.resolve(res);
        } else {
          callback(err, res);
        }
      });

      return returnVal;
    };
So if I call myAsyncFunc(foo, bar) it returns a promise and if I call myAsyncFunc(foo, bar, cb) it returns itself for chaining.

Re: Sane Async Patterns in JavaScript

#25

Post by IgorPartola »

mtdewcmu wrote: post #15

"Nested spaghetti" strikes me as a mixed metaphor. I'd have to ask an expert on Italian cuisine, but I don't think spaghetti nests. Literary aspects aside, I don't think the "pyramid of doom" is what is meant by spaghetti. In the pyramid, it's easy to see the sequence in which things happen. In spaghetti code, it's hard to see the sequence -- that's the problem. The fact that the pyramid makes it easy to see the sequ…

It's easy to see what's happening if everything is written in one file. It's hard if your callback are fired from and/or go into minimized library code you don't control or don't want to debug. You may have your own pyramid, but it's really sitting on someone else's pyramid.

Re: Sane Async Patterns in JavaScript

#26

Post by rictic »

mtdewcmu wrote: post #15

"Nested spaghetti" strikes me as a mixed metaphor. I'd have to ask an expert on Italian cuisine, but I don't think spaghetti nests. Literary aspects aside, I don't think the "pyramid of doom" is what is meant by spaghetti. In the pyramid, it's easy to see the sequence in which things happen. In spaghetti code, it's hard to see the sequence -- that's the problem. The fact that the pyramid makes it easy to see the sequ…

Yeah, the real problem for me with the nested case is error handling. It's all manual, and the default (unless you're very careful) is that errors do not propagate and will instead simply be lost and ignored.

Re: Sane Async Patterns in JavaScript

#28

Post by Silhouette »

IME, most clutter from async logic in JavaScript, however it's dressed up, only happens at all because of implementing something that is fundamentally sequential and synchronous using the wrong tools for the job. The slide "A JS-er's lament" was a great demonstration of how fundamentally broken the current JS model is.

Put another way, the obviously missing pattern to me is to just move the concurrency up to the level of having multiple threads, and then use synchronous interfaces for synchronous operations. Now that Web Workers are starting to become more widely supported, I don't understand why we aren't heading for synchronous APIs as fast as humanly possible.

Re: Sane Async Patterns in JavaScript

#29

Post by Groxx »

jgreen10 wrote: post #22

Have you tried state machines? My JS programming often looks something like: https://gist.github.com/anonymous/5314313 I don't really care if the APIs I use have callbacks or promises, both fit in just fine.

Nice example :) I tend to think state machines are underused, they give you wonderfully predictable behavior.
Post reply on HN