Live data from Hacker News

Node v7.5.0 Released

github.com

101–110 of 142 posts

Re: Node v7.5.0 Released

#101

Earlier quoted context omitted.

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/

According to the site: Node.js ES2015 Support is at 99% for v8.0.0 nightly. Node.js ES2017 Support is at 74% for v8.0.0 nightly.

Oh right I totally missed that the header changes as you scroll !

Re: Node v7.5.0 Released

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

Tried with node.js for a few months and now back to php7/lavarel, node.js eco-system still evolves quickly and I need a stable backend right now, so far php7 works well for me and seems the development is faster.

Re: Node v7.5.0 Released

#103
post #52

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…

Nit, but await is an operator, not an annotation on a statement. So that should be written as:

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

Re: Node v7.5.0 Released

#104
post #34
post #28

Earlier quoted context omitted.

I don't understand

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

Technically you can use the latest version of Nodejs in lambda by bundling the binary with your lambda package and use the handler script to run the binary. The binary need to be compatible with Amazon Linux though, so you'll probably need to compile the binary on an ec2 instance running Amazon Linux.

Re: Node v7.5.0 Released

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

TypeScript async/await helps a lot with this. Type safety plus async ops. Awesomeness.

Re: Node v7.5.0 Released

#106
post #99

Earlier quoted context omitted.

To be fair, 4.3.2 the current LTS version, but would ideally be migrated prior to April. https://github.com/nodejs/LTS

Isn't node v6 the current LTS version? I think each even major version is LTS, and 6 is the latest one of those.

v6 is indeed LTS.

Re: Node v7.5.0 Released

#107
post #99

Earlier quoted context omitted.

To be fair, 4.3.2 the current LTS version, but would ideally be migrated prior to April. https://github.com/nodejs/LTS

Isn't node v6 the current LTS version? I think each even major version is LTS, and 6 is the latest one of those.

There is an overlap. Both V4 and V6 are currently LTS until April.

Re: Node v7.5.0 Released

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

TypeScript async/await helps a lot with this. Type safety plus async ops. Awesomeness.

I feel like it should be clarified here that async/await is not exclusive to TypeScript, but a ES7 (?) feature that is also available if you use the Babel transpiler.

Having type safety is great of course, but it might be too heavy to add if you just want good async handling.

Re: Node v7.5.0 Released

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

The huuge difference once you understand its implications is that you can:

    return function().then(() => ...).then(() => ...)
...and the caller of you function can decide to chain even more stuff after, in the simplest case. Most obvious benefits, though not the biggest, is that you simply can return a promise ad drop the ugly extra callback argument that you function needs to have. For example:

    function foo(cb) {
        async.waterfall([
            function(){},
            function(){},
        ])
    }
becomes:

    function foo2() {
        return function()
            .then(function(){})
            .then(function(){});
    }
...and this way the logic ends up where it should be, in the caller, not the callee!

Another simple to explain benefits are the fact that you can .then() a promise 10 times and what it does will only happen once, and then the other times you'll just consume the result. You don't need to care if something is (a) already computed, (b) in the process of being computed, (c) scheduled for computation later etc., you can write the exact same code for all cases. Because you're working with values that have dependencies between this, not with processes that need to happen in a certain order.

The bigger benefits show up when you write more and more code and you see how beautifully it all untangles with promises.

And the fact that once you learn promises you can carry further the knwledge to other async patterns like co and async/await (they are all understandable in terms of promises).

Do yourself and everyone you work with a favor and move away from async please, especially in a team promises make everything so much easier to understand! Same advice of you're writing nodejs libraries: have you functions return promises instead of take callbacks! Drop the intellectual lazyness and grow beyond "async by callbacks", it's the worst coding style ever. And everyone will be able to convert almost instantly from promises to async/await since the logic is similar, just syntactic sugar comes over it.

Post reply on HN