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

1–10 of 30 posts

Re: Sane Async Patterns in JavaScript

#2

Post by dap »

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 the same one is called (or emitted) early or too many times. IME, these are the really hard problems to debug in async JavaScript, and there are improvements available (I wrote node-vasync for this), but I still wouldn't say it's well solved by any of these approaches.

Re: Sane Async Patterns in JavaScript

#3

Post by quarterto » 

  Next 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

Re: Sane Async Patterns in JavaScript

#7

Post by skylan_q »

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 it explicit in the function name... but that's just how I handle it.

Re: Sane Async Patterns in JavaScript

#8

Post by joshguthrie »

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…

If that function is "supposed" to be async and its last argument is not something looking like "callback", there's a great chance it's a Promise.

Otherwise, there's no "naming scheme" for promise-based functions.

Re: Sane Async Patterns in JavaScript

#9

Post by jlogsdon »

xpaulbettsx wrote: post #5

This "PubSub" pattern is really trying to recreate RxJS but without the expressiveness - if you find yourself doing this kind of work a lot, you should check it out http://reactive-extensions.github.com/RxJS https://github.com/Reactive-Extensions/RxJS

PubSub is pre-node, making RxJS a "more expressive" PubSub.

Re: Sane Async Patterns in JavaScript

#10

Post by joshguthrie »

quarterto wrote: post #3

Next 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.
Post reply on HN