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.
Node v7.5.0 Released
101–110 of 142 posts
Re: Node v7.5.0 Released
#102There 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?
Re: Node v7.5.0 Released
#103Earlier 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…
const [a, b] = await Promise.all([getA(), getB()]);Re: Node v7.5.0 Released
#104Earlier 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...
Re: Node v7.5.0 Released
#105There 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?
Re: Node v7.5.0 Released
#106Earlier 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.
Re: Node v7.5.0 Released
#107Earlier 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.
Re: Node v7.5.0 Released
#108There 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.
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
#109There 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?
Re: Node v7.5.0 Released
#110Earlier 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…
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.