These patterns apply to Javascript, which I wasn't expecting from the title. Mods, could you edit in "Javascript" somewhere in the title, please?
Sane Async Patterns in JavaScript
11–20 of 30 posts
Re: Sane Async Patterns in JavaScript
#12While 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…
Functions should be documented with the types of their parameters and return value.
Re: Sane Async Patterns in JavaScript
#13While 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…
Functions should be documented with the types of their parameters and return value.
I suppose I've just learned to really appreciate the "?" and "!" at the end of ruby function names...
Re: Sane Async Patterns in JavaScript
#14The bit about AMD didn't really fit in with the rest. Why start talking about module loading when you were discussing async earlier? They are completely separate issues.
Re: Sane Async Patterns in JavaScript
#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 sequence, i.e. follow the chain of causation, and easy to find the callbacks, argues that there is a place for it. Additionally, it makes it easy to transfer state through the chain, since each callback has access to the previous one's variables.
The other patterns, which probably all have appropriate uses, too, would seem to carry a greater risk of spaghetti -- i.e. control that jumps around unexpectedly and is hard to follow.
Re: Sane Async Patterns in JavaScript
#16Next time you're about to define a function with a callback argument, don't. No, do. It's the prevailing style in Node.js and elsewhere, and so there exist tools to transform them (syntactically or otherwise) into more palpable styles: https://github.com/0ctave/node-sync https://github.com/BYVoid/continuation https://github.com/JeffreyZhao/wind https://github.com/Sage/streamlinejs
I already knew about node-sync, but continuation really brings something new. I'll check the source to understand what it does under the hood.
Also, the comparison on the project's README is informative (and lists additional options):
Re: Sane Async Patterns in JavaScript
#17Promises are about as clean as you can get in a purely async environment.
Yet, notice how no one shows off how easy it is to write a loop. Oh, and what happens when your code throws an exception? It's as though that path halted forever.
Also, what happens when you have a method defined as
result = foo(args);
that now needs to perform an async operation? Enjoy refactoring every call site.
Re: Sane Async Patterns in JavaScript
#18That twitter quote is pretty funny.
Re: Sane Async Patterns in JavaScript
#19Next time you're about to define a function with a callback argument, don't. No, do. It's the prevailing style in Node.js and elsewhere, and so there exist tools to transform them (syntactically or otherwise) into more palpable styles: https://github.com/0ctave/node-sync https://github.com/BYVoid/continuation https://github.com/JeffreyZhao/wind https://github.com/Sage/streamlinejs
I agree, I often will write promise wrappers for other people's stuff, but for the external surface of my module I have callbacks.
Also, callbacks ARE sometimes nicer than promises, etc... especially if you have CoffeeScript function syntax.
Re: Sane Async Patterns in JavaScript
#20Sometimes require.js feels a bit heavy for what is mostly a straightforward concept (AMD), so I use a much simplified version of the pattern: https://gist.github.com/potch/4156519