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

81–90 of 142 posts

Re: Node v7.5.0 Released

#81

Post by devwastaken »

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…

Promises don't cover a lot of scenarios in async usage. When building some node apps, especially toolage, doing everything async just isn't possible, or is a lot more work for little benefit. The second you use a promise, anywhere, working with its output is now also async, you cannot 'wait' for it. I don't know if async/await actually does this or not, but until that functionality exists in JS, working with node, for me, is a pile of junk code, especially when libraries force you to use them asynchronously.

Re: Node v7.5.0 Released

#83

Post by cookiesboxcar »

MehdiHK wrote: post #41
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?

We've been using async/await (transpiled with babel) for last one year in our production API code. There really is not any need to use those async control flow libraries anymore.

Agree, except we use TypeScript as the transpiler. Async/Await down to es5. Works like a dream.

Re: Node v7.5.0 Released

#84

Post by jcheng »

vkjv wrote: post #52
zachrose wrote: post #45

Earlier quoted context omitted.

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?

In my opinion, these are the major ones: 1. Promises are a value. They can be passed to other functions. This simplifies a lot of control flow. 2. The `.then` method on a promise is similar to `flatMap` in other languages / libs. The next chain will wait for any nested promises to complete. This flattens callbacks so you can see the flow instead of the pyramid of doom. 3. Native promises include a bit of sugar, such…

5. Error handling and even successful termination is very, very easy to get wrong with nested callbacks (forgetting to call a callback, or forgetting to catch unexpected exceptions and pass them to the callback, means the function never returns at best or brings down the whole process at worst). Promises make this much easier by automatically propagating errors for you down the promise chain (though you or your caller do still need to handle the error at the end of the chain).

Re: Node v7.5.0 Released

#85

Post by always_good »

athenot wrote: post #75
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?

This is probably not the answer you're looking for, but you could look into ways that make callbacks enjoyable. The syntactic sugar provided by CoffeeScript goes a long way to make readable (and, dare I say, elegant) what would be a tangled mess in straight up JavaScript: # Get profiles LIST as JSON .post "/list", (req, res) -> db.maria.query getProfilesQuery, { userId: req.session.passport.user }, false .on "result"…

What impedes readability here is that you don't simply have an async function `getProfiles({ userId })` that gives you a list of profiles, either taking a callback or returning a promise.

A lot of that is pointless noise. You don't need to set the status code to 200 or call end(). `res.json(profiles)` will do.

And these days, Coffeescript is just Javascript with some optional parens. Can't think of many upsides in 2017 to not just using ES6.

Re: Node v7.5.0 Released

#87

Post by jcheng »

spion wrote: post #54
norswap wrote: post #46

Earlier quoted context omitted.

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.

Because the standard library doesn't really have that many callback based functions. The more important issue here is that Promises are seen as fundamentally incompatible with post-mortem debugging due to their empty-the-stack requirement: https://promisesaplus.com/#point-34 If the stack is emptied when handling an exception, the context in which that exception happened is completely lost, so its not clear how to get…

Both Q and bluebird promises optionally support long stack traces, albeit at a performance hit. And in practice even old style callbacks often (usually?) empty the stack.

Re: Node v7.5.0 Released

#88

Post by gsathya_hn »

GeneralMaximus wrote: post #30
ykler wrote: post #24

Earlier quoted context omitted.

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, pa…

Native promises and bluebird use different microtask queues on Node which makes interop incorrect (which is also one of the reasons why bluebird is ES6 spec non compliant). See https://gist.github.com/anonymous/9936c695f2c29e79a0c1a0dec8...

This might lead to subtle ordering bugs, I would recommend against using both together.

Using bluebird and native promises together may result in slower performance because V8 has fast paths for native promises which fail for bluebird.

Re: Node v7.5.0 Released

#89

Post by simlevesque »

0X1A wrote: post #86

I don't keep up with node end ES version compliance but is there a scheduled release that'll target all ES6 features?

I don't think so. They try as hard as possible. A lot of it is directly related to V8. In Node.JS v8.0.0 nightly they currently support 70% of the ES2015 spec without flags.

You can check the progress here: http://node.green/

Post reply on HN