Promises?

[alexandrosm]

Just wanted to check what your attitude towards using promises to manage asynchronous calls in decking is.

We've recently converted pretty large internal codebases from async.js to promises and the code became smaller, more declarative, and cleaner at the same time.

Then, moving to using bluebird as a promise library meant even performance is superior than async.js which is completely counterintuitive given the extra machinery, but the author of bluebird is pretty crazy/awesome.

Not sure if I or someone else in the resin.io team can put in the time to do the conversion for decking, but I can try and answer that question depending on your response.

I can certainly work with async,js, so it's not a problem if you want to keep on using it for decking. Just thought I'd check.

[makeusabrew]

I'm on the fence about promises. If all async operations could be flattened into a single chain I think I'd be sold, but some things want to run concurrently, some want limited concurrency, some want to run in a chain but a chain we build up programatically (which I know is just as doable with promises, but loses the elegance of them). I admit I haven't used them a great deal in anger, certainly not in Node.js (more browser-based stuff) so I'm sure most of my resistance comes from ignorance more than anything.

At the moment I don't have any great incentive to switch to be honest - though I'm more than willing to listen to other opinions.

[alexandrosm]

I'll ping @page- , our resident promises-expert who can probably contribute more to this than I can. Not an urgent issue at all, but worth discussing I reckon.

[stephenmelrose]

I did some looking into promises a few months ago. I think they have a lot to offer to frond-end dev, but I feel async is a much better fit for Node. It still abstracts some of the asynchronous workflows from you, but you have a lot of control, and more importantly more workflow options.