Hacker News Reader

Comment by mambodog | Hacker News Reader

Why is it that most of the articles which pop up complaining about node's concurrency options don't even mention streams? For most data-manipulation tasks, FRP-style composition of higher order operations on streams turns out to be the best choice; not callbacks, promises, etc. Not even bringing them up in a discussion of concurrency in node makes it hard to take the article seriously.

View on HN

"everything they call is callback based, returns a Q promise, returns a native promise, is a generator, is a pipe, or some other weird thing because it’s Node.js. (Just tell them to check the type signatures.)"

I think this addressed your question indirectly.

Not sure I've ran across what you're describing. Are you talking about using streams as an option to get around callback hell? Have a link describing this?

http://caolanmcmahon.com/posts/how_i_want_to_write_node_stre...

http://highlandjs.org/

https://github.com/dominictarr/event-stream

http://reactive-extensions.github.io/RxJS/

Yes, streams/pipes/channels/whatever can be great for certain classes of problems. I omitted them because I very very rarely see them used in Node.js. They are probably under-utilized and I simply didn't have enough examples to think about, since the overwhelming majority of the libraries and code I've encountered use callbacks. It could be a great topic to write about if you have the time.

But what about when you need the whole object in memory before you want to work with it? Also, many of the libraries written for nodejs are not necessarily stream-ready -- but I would argue most are callback-ready.

Reply on news.ycombinator.com