Live data from Hacker News

Node v7.5.0 Released

github.com

51–60 of 142 posts

Re: Node v7.5.0 Released

#51
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?

Because promises are chainable, it can take N level-deep code down to 1 level deep. So that's your first big win.

The second one is that you can await a promise, which turns your 1-level-deep code to 0 levels deep.

Re: Node v7.5.0 Released

#52
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?

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 as Promise.all. You need a library to do this with callbacks.

4. Promises are the backbone of async/await. You need them to use it.

Example:

    await const [a, b] = Promise.all([getA(), getB()]);

Re: Node v7.5.0 Released

#53

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?

You can take the part before `.then()` and pass it around.

yes that works quite great. you have to define a 'async' function, in which you can use the 'await' keyword.

async getDoc(doc) {

  const result = await db.get(doc)

  console.log('result:', result)
}

// instead of:

function getDoc(doc) {

  db.get(doc, result => {
    console.log('result:', result)
  });
}

// or

function getDoc(doc) {

  db.get(doc)
    .then(result => 'result: ' + result)
    .then(::console.log)
    .catch(::console.error)

}

Re: Node v7.5.0 Released

#54
post #46
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.

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 the process to dump a core that contains meaningful information regarding the problem.

This is whats currently blocking node from fully switching to promises. Apparently many companies that have influence in node core rely heavily on post-mortem debugging and don't find the situation acceptable.

Re: Node v7.5.0 Released

#55
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?

Chaining and returning can keep things nice and neat. Say you are following a Controller -> Service -> Repo implementation.

Controller calls the service.

Service returns a call to a repo with any mapping that needs to occur.

Repo calls out to database or external api and returns the promise.

Makes the work very boring and repetitive for the most part which is a good thing I think.

    function someController(req, res) {
        UserService.getUser(req.session.user)
            .then(SomeService.getSomething)
            .then((val) => res.json(val))
            .catch(handleError);
    }

    function getSomething(user) {
        return SomeRepo.getSomething(user)
            .then(MapSomething)
            .catch(alternativeHigherLevelCatch);
    }

    function getSomething(user) {
        return new Promise((resolve, reject) => {
            database.getSomething(
                'defined parameters',
                user,
                resolve,
                reject
            )
        });
    }

Re: Node v7.5.0 Released

#56
post #36

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.

> it encourages a lot of callback hell we've found at my company

This is a very odd comment. async provides the same level of indentation as Promises does:

  async.waterfall([
    function(){},
    function(){},
  ])
Here's promises doing the same thing:

  function()
  .then(function(){})
  .then(function(){})
One's a list of functions to be run in order, the other uses method chaining. You may prefer one or the other but saying async 'encourages callback hell' is about as logical as saying promises does.

__Edit__: further to my own comment. The people I know who know their stuff (ie, work on JS itself) and like/prefer Promises do so because they believe that functions should return values.

I don't think anything will be better than either solution until async/await gains wide support. Async/await needs return values, so hence promises, so it's definitely worth knowing promises. But yeah, right now async is fine.

Re: Node v7.5.0 Released

#57

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…

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

IMO promises and Bluebird made `async` obsolete.

Re: Node v7.5.0 Released

#58
post #48
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.

I agree with you but FWIW there are both big (Bluebird) and small (pinky-promise) packages to promisify stuff.

Re: Node v7.5.0 Released

#59
post #43
post #34

Earlier quoted context omitted.

"AWS Lambda supports the following runtime versions: Node.js – v4.3.2" http://docs.aws.amazon.com/lambda/latest/dg/current-supporte...

Better than the Python story, at least ...

Yeah! Sadly, if you wanna do actual Python (3.x?) stuff on aws you're better off rolling your own or paying premium to "have it all solved" on heroku :((

Re: Node v7.5.0 Released

#60

Earlier quoted context omitted.

My understanding was that Node didn't support native ES6, is that no longer the case? Or are you talking about using a transpiler?

Node has supported all of ES6 except modules since 6.0.

Ah, this explains it. I tried to use an import statement a couple days ago and it failed, so I assumed it still wasn't supporting ES6. Good to know!
Post reply on HN