Live data from Hacker News

Node v7.5.0 Released

github.com

71–80 of 142 posts

Re: Node v7.5.0 Released

#71
post #56
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.

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

It also provides more specific control flow functions that are bug-prone to roll your own with promises. I've learned a lot by looking at the source!

Re: Node v7.5.0 Released

#72

Earlier quoted context omitted.

Add --harmony flag to enable stable ES7 features (or transpile with Babel) and use async/await, it's marvellous.

Node 8.0.0 has it enabled without --harmony. Will be a great release to upgrade to.

Node 8 has not been released.

Re: Node v7.5.0 Released

#73
post #29
post #19

Earlier quoted context omitted.

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.

Good to know! I have an app running on it but haven't touched it in a while.

Re: Node v7.5.0 Released

#74
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 should have added that I'm asking to compare the special parts (e.g. reduce, waterfall, etc) of Bluebird vs the async library.

Re: Node v7.5.0 Released

#75
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", (result) ->
        rows = []
        res.status(200)
        result
          .on "row", (row) -> rows.push row
          .on "error", (error) -> logger.warn error
          .on "end", -> 
            res.json rows
            res.end()
5 callbacks here but they don't impede readability.

Re: Node v7.5.0 Released

#76

> Use system CAs instead of using bundled ones Does this make the npmrc config for cafile redundant now in my MITM environment? The amount of projects that just can't handle the CA or worse, a proxy setting, is very irritating. Will we not have to make a separate config for every app that also bundles node (e.g. vscode) or anything that uses node to get a file (vue-cli, node-pre-gyp, etc)?

I recently left a job that has a proxy. I would estimate the my time spent there working on proxy related issues to be more than 2 months over the 5 years I was there. Is it too unreasonable to evaluate the cost of these proxies beyond the maintenance cost?

Re: Node v7.5.0 Released

#77
post #75
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"…

Maybe it's just me, but this would look infinitely more readable to me if I could tell where each callback starts and where it ends, i.e. in plain JavaScript.

Re: Node v7.5.0 Released

#78
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…

Bluebird is faster than native promises as well.

http://softwareengineering.stackexchange.com/questions/27877...

Re: Node v7.5.0 Released

#79
post #56
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.

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

Promises also work better with Typescript, since it's well defined which type each step returns and which the next function expects. That means the .then(a => next(a)) cascades can be typechecked well. async.waterfall doesn't seem to be typecheckable.

Re: Node v7.5.0 Released

#80

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…

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

You can always check here: http://node.green
Post reply on HN