111–120 of 142 posts
Earlier quoted context omitted.
In 7.2.x, you could do async await with just a --harmony flag.
I might be mistaken but I believe there were some major performance issues with the older async/await implementation.
Earlier quoted context omitted.
> 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) { asy…
Also: not sure if you mean 'you' singular or 'you' plural, but personally I use a combination of callbacks for node stuff with basic async patterns applied (not the 'async' module) and promises.
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?
http://callbackhell.com/ I think the mental gymnastics needed to write non blocking code also makes you understand the flow of your program, witch allows good abstractions. After a while it becomes a second nature and you get a mental picture of all branches. Thinking about code as events (button.onclick = showPicture), makes you a better programmer, as this is how a computer work. And when your program has to scale…
Promises are a band-aid that gives you shallower indentation, and then simply hides the callback complexity in invisible objects that are even harder to debug.
The problem is the modern web development world is all about creating two classes of programmer: framework programmers who control their entire stack, and application programmers who suckle at the teat and can't modify libraries, only writing composite works out of building blocks.
Application programmers only feel safe when they have an exhaustive palette of libraries that they can use, because they know they can't modify anything. They thrive on feeling taken care of.
Framework programmers only feel good about themselves when they know they're working on something so complicated that application programmers will never be able to understand it. They enjoy creating an simple interface for the common man, while solving "hard problems" in abstract domains. They thrive on superiority.
This creates an impermeable layer that can never be refactored (framework programmers don't have access to app code, app programmers can't modify the frameworks). So when someone encounters callback hell, the necessary refactoring to find the right interfaces is impossible.
Promises work well in this dead layer, because they create a clear boundary of responsibility between these two kinds of programmers. But the cost is thousands of tiny invisible state machines, with no labels or semantics.
Earlier quoted context omitted.
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…
a()
.then(()=>b())
.then(()=>c())
a():
b();
c();
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
IMO promises and Bluebird made `async` obsolete.
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.
Edit: My experience is with babel's generator version of async/await, so other transformations may be easier to work with.
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…
Parent: "You have a number of ways"
Do you see the irony?
Earlier quoted context omitted.
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 !
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 .
Have they fixed the middleware graveyard? When I last used it, I found it insanely difficult to pick the correct middlewares due to the changes between versions.
But I've never run into an issue that was "insanely difficult".
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?
doSomething.then(stepTwo).then(stepThree).catch(errHandler);