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

21–30 of 142 posts

Re: Node v7.5.0 Released

#21

Post by GeneralMaximus »

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?

You have a number of ways of keeping a handle on async code now.

1. Native ES6 promises will cover most of your basic needs. See https://developer.mozilla.org/en/docs/Web/JavaScript/Referen.... In fact, unless you have very specific needs not covered by native promises, you shouldn't drop a third party library into your project.

2. For more advanced operations on promises, use Bluebird. See http://bluebirdjs.com and http://bluebirdjs.com/docs/api-reference.html. It has a ton of features built on top of native ES6 promises. If you're using an older version of Node, it also acts as a polyfill. It can also make it easy to work with libraries that only expose a callback-based interface. So yeah, Bluebird is the shit.

3. co is a generator-based control flow library that can make your async code look more like synchronous code. It's pretty cool, but I haven't personally used it in a project, nor do I know of anyone else who uses it. It builds on top of promises and generators, and isn't very hard to understand under the hood. See https://github.com/tj/co. I wouldn't recommend it, but it might be something to play with because ...

4. ... async/await is coming to JavaScript! At a very high level, this pair of keywords is syntax sugar for what co already does as a library. This is the final stage in the evolution of taming callback hell in JavaScript, and it builds on top of everything that has come before (promises and generators). Here's a tutorial: https://blog.risingstack.com/async-await-node-js-7-nightly/

Re: Node v7.5.0 Released

#22

Post by lossolo »

_puk wrote: post #18
lossolo wrote: post #11

Earlier quoted context omitted.

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.

I imagine the likes of Babel currently hide all of this in the Node context, but is there a move to either change the standard API to async/await, or provide a standard mirror API? Either option sounds full of compatibility / maintainability headaches, so how does Node get from its current state of callback hell out the box to async / await? goroutines aren't magically turning async calls into sync, just hiding them…

> is there a move to either change the standard API to async/await

From what I remember there was no plans to change that (based on discussion from couple of months ago by node members on github).

> Either option sounds full of compatibility / maintainability headaches

It is.

> goroutines aren't magically turning async calls into sync, just hiding them deeper "under the hood"; there must be hope for Node.

Of course it's not about turning code into sync one, it's about coding style to look like it would be a sync one. But in case of Go it was created with this as main language concept, everything was designed around it, scheduling, user space lightweight stacks for gorutines etc.

Re: Node v7.5.0 Released

#23

Post by eknkc »

fiiv wrote: post #20
SpencerWood wrote: post #9

Earlier quoted context omitted.

Can't wait... need me some async await without babel.

In 7.2.x, you could do async await with just a --harmony flag.

I might be mistaken but I believe there were some major performance issues with the older async/await implementation.

Re: Node v7.5.0 Released

#24

Post by ykler »

GeneralMaximus wrote: post #21
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?

You have a number of ways of keeping a handle on async code now. 1. Native ES6 promises will cover most of your basic needs. See https://developer.mozilla.org/en/docs/Web/JavaScript/Referen... . In fact, unless you have very specific needs not covered by native promises, you shouldn't drop a third party library into your project. 2. For more advanced operations on promises, use Bluebird. See http://bluebirdjs.com and…

I am confused. Your recommendations 1 and 2 seem to conflict with one another. I use Bluebird now for promisification, and I also used a few other features including the resource management (disposers). Does this mean that I will be using Bluebird and not native promises for the foreseeable future? Or can/should I use Bluebird with native promises? (Or would that just make things slower if it is even possible?)

Re: Node v7.5.0 Released

#25

Post by egeozcan »

eknkc wrote: post #23
fiiv wrote: post #20

Earlier quoted context omitted.

In 7.2.x, you could do async await with just a --harmony flag.

I might be mistaken but I believe there were some major performance issues with the older async/await implementation.

Yes, on the other hand, if you are like me and use them for one-off scripts, they are great.

Re: Node v7.5.0 Released

#26

Post by nodesocket »

GeneralMaximus wrote: post #21
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?

You have a number of ways of keeping a handle on async code now. 1. Native ES6 promises will cover most of your basic needs. See https://developer.mozilla.org/en/docs/Web/JavaScript/Referen... . In fact, unless you have very specific needs not covered by native promises, you shouldn't drop a third party library into your project. 2. For more advanced operations on promises, use Bluebird. See http://bluebirdjs.com and…

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

Re: Node v7.5.0 Released

#27

Post by k__ »

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?

There is also a Reactive Extensions implementation available to handle async stuff.

So if you know these from another language, RxJS is worth a try :)

Re: Node v7.5.0 Released

#29

Post by ffiw »

aswerty wrote: post #19
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?

The Koa web framework built by the guys behind Express is pretty neat. You can do stack like calls with it, rather than callbacks, via generator functions. Not sure what the uptake is like but you can find more at http://koajs.com .

Latest version has replaced generators with async/await.

Re: Node v7.5.0 Released

#30

Post by GeneralMaximus »

ykler wrote: post #24
GeneralMaximus wrote: post #21

Earlier quoted context omitted.

You have a number of ways of keeping a handle on async code now. 1. Native ES6 promises will cover most of your basic needs. See https://developer.mozilla.org/en/docs/Web/JavaScript/Referen... . In fact, unless you have very specific needs not covered by native promises, you shouldn't drop a third party library into your project. 2. For more advanced operations on promises, use Bluebird. See http://bluebirdjs.com and…

I am confused. Your recommendations 1 and 2 seem to conflict with one another. I use Bluebird now for promisification, and I also used a few other features including the resource management (disposers). Does this mean that I will be using Bluebird and not native promises for the foreseeable future? Or can/should I use Bluebird with native promises? (Or would that just make things slower if it is even possible?)

Automatic promisification and the disposer pattern are both Bluebird-specific features that native ES6 promises don't support, so you'll have to continue using Bluebird if you rely on them.

However, promises returned by Promises/A+ compliant libraries -- and this includes native ES6 promises -- are interoperable with each other. That means you can mix Bluebird promises with native promises for the most part. E.g, passing an ES6 promise to Bluebird's Promise.all will work just fine. This works up to a point, and breaks when you try to use a Bluebird-specific function that's expecting additional functionality to be attached to the promise object.

I don't see why mixing Bluebird promises with ES6 promises would make anything slower. You shouldn't worry about this.

Post reply on HN