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

Node v7.5.0 Released

github.com

Post reply on HN
Print view View original

61–70 of 142 posts

Re: Node v7.5.0 Released

#61

Post by increment_i »

Bahamut wrote: post #36
nodesocket wrote: post #26

Earlier quoted context omitted.

Also highly recommend the npm async library[1] even though the hipster way is now native async/wait or promises. caolan/async has some amazing sugar on nearly every use-case the most common for me being async.auto(). [1] https://github.com/caolan/async

I highly recommend against using that library - it encourages a lot of callback hell we've found at my company, and it is much harder to create nice reusable functions with it vs. promises. bluebird is a wholly superior library for handling async flow.

I use Node a lot, and I find myself reaching for the async library any time the project reaches a non-trivial size and there's a lot of communication going on between services. I don't find it all that hard to read (the async.waterfall method looks somewhat like promises chaining) I suppose I should spend a weekend or two steeping myself in promises and es7. It's mildly annoying to have to learn a new async paradigm every couple years, and like others have pointed out, the Node core hasn't changed - its still callbacks.

Re: Node v7.5.0 Released

#62

Post by always_good »

ihsw wrote: post #48
bmpafa wrote: post #44

Earlier quoted context omitted.

Promises have been native in node for awhile, so any time you spend in callback hell is entirely your prerogative.

Wrapping every standard library method with my own promises sounds like just another flavour of hell, and it still doesn't address the fact that the standard library is callback hell.

Callback hell isn't the characteristic of having a callback-based API. It's the code you get when you try to compose it and conditionally fork it without any better abstractions.

So promisifying a callback-based API does address it by either letting you use a yield/await abstraction or at the very least promise composition.

Wrapping a callback-based API is such a mechanical process that you can wrap entire modules at a time, so I'm not sure what's hellish about that when it gives you promises, something you can actually work with.

Re: Node v7.5.0 Released

#63

Post by Hurtak »

norswap wrote: post #46
SeanDav wrote: post #3

There is a lot to like about Node. I had a look a couple of years ago but lack of a definitive library to handle callback hell put me off. How is the situation these days?

Many people are complaining that the standard library still uses callbacks and so even though you have async/await, you can't use it with the standard library. I wholeheartedly agree. I don't understand why someone hasn't build a compat library that simply promisifies all the standard library (it isn't that big), taking the edge cases into account.

From my experience majority of async functions that I used are from the fs package and for that, there is nice wrapper called fs-promise (1) which converts all the functions from callbacks to promises.

For other stuff, I just create my own promise wrapper (if I feel like that promise interface would be better), which is like 5 lines of code.

[1] https://www.npmjs.com/package/fs-promise

Re: Node v7.5.0 Released

#64

Post by alleycat »

norswap wrote: post #46
SeanDav wrote: post #3

There is a lot to like about Node. I had a look a couple of years ago but lack of a definitive library to handle callback hell put me off. How is the situation these days?

Many people are complaining that the standard library still uses callbacks and so even though you have async/await, you can't use it with the standard library. I wholeheartedly agree. I don't understand why someone hasn't build a compat library that simply promisifies all the standard library (it isn't that big), taking the edge cases into account.

Promises are coming: https://github.com/nodejs/node/pull/5020

Re: Node v7.5.0 Released

#65

Post by always_good »

lossolo wrote: post #11
SeanDav wrote: post #3

There is a lot to like about Node. I had a look a couple of years ago but lack of a definitive library to handle callback hell put me off. How is the situation these days?

Whole standard api is still using callbacks so you would need to write your wrappers around it to not use callbacks.. And async/await is not solving anything because your definitions of fuctions will still need callbacks/promises under the hood anyway (unless you use libraries that do it for you). I like how Go solves that, gorutines and you write your code as it would be normal sync code.

    > And async/await is not solving anything because 
    > your definitions of fuctions will still need 
    > callbacks/promises under the hood anyway
The point is that you can write your complex business logic with async/await which is easier to follow and get right. I mainly use it in my routers and database modules.

It doesn't need to factor out every .then() or callback from your codebase to be incredibly useful or to fulfill its purpose.

Re: Node v7.5.0 Released

#66

Post by lenkite »

SeanDav wrote: post #3

There is a lot to like about Node. I had a look a couple of years ago but lack of a definitive library to handle callback hell put me off. How is the situation these days?

RxJs (or equivalent FRP streams library) handles this perfectly.

Re: Node v7.5.0 Released

#67

Post by sixbrx »

lossolo wrote: post #11
SeanDav wrote: post #3

There is a lot to like about Node. I had a look a couple of years ago but lack of a definitive library to handle callback hell put me off. How is the situation these days?

Whole standard api is still using callbacks so you would need to write your wrappers around it to not use callbacks.. And async/await is not solving anything because your definitions of fuctions will still need callbacks/promises under the hood anyway (unless you use libraries that do it for you). I like how Go solves that, gorutines and you write your code as it would be normal sync code.

For the few std lib calls that I make in web apps, I just use Bluebird to promisify() node style callbacks into promise style code, always worked fine for me.

Re: Node v7.5.0 Released

#68

Post by zubi »

SeanDav wrote: post #3

There is a lot to like about Node. I had a look a couple of years ago but lack of a definitive library to handle callback hell put me off. How is the situation these days?

Someone already mentioned about the co library. My personal experience is that it is excellent and massively simplifies async calls. The API resembles the async/await pattern: you use the keyword "yield" instead of "await". Async calls look as if they are sync. The code that includes heavy use of async methods such as in a database application greatly benefits from co in terms of code readability.

Re: Node v7.5.0 Released

#69

Post by disease »

zachrose wrote: post #45
Bahamut wrote: post #36

Earlier quoted context omitted.

I highly recommend against using that library - it encourages a lot of callback hell we've found at my company, and it is much harder to create nice reusable functions with it vs. promises. bluebird is a wholly superior library for handling async flow.

So much of the promise-based code I see looks almost the same as it would with plain callbacks, just with the callbacks plopped into .then(). Am I missing something? How do promises make for more reusable functions?

I'm surprised no one has mentioned my favorite aspect of Promise, which is the fact that you can plop a .catch at the end of a chain and it will do the error handling there regardless of where in the chain it failed. Doing this with long chains of asynchronous calls before Promise was a huge pain in the ass.

Re: Node v7.5.0 Released

#70

Post by z3t4 »

SeanDav wrote: post #3

There is a lot to like about Node. I had a look a couple of years ago but lack of a definitive library to handle callback hell put me off. How is the situation these days?

http://callbackhell.com/

I think the mental gymnastics needed to write non blocking code also makes you understand the flow of your program, witch allows good abstractions. After a while it becomes a second nature and you get a mental picture of all branches.

Thinking about code as events (button.onclick = showPicture), makes you a better programmer, as this is how a computer work. And when your program has to scale across several CPU's or servers, it will come naturally to you.

Multi threaded solutions can be easier at first, but when you need to have threads that communicate, and handle locks etc, that too becomes hard.

Post reply on HN