I'm just a developer not so much a core contributor so forgive me if I'm missing something, but I can't help but wonder:
- With the JS ecosystem evolving so rapidly, what happens when some other async flow-control pattern displaces promises in 6, 12, 18 months? Another semver major bump & major BC break?
- With respect to "If it ain't broke, don't fix it", what's "broke?" I love promises & use them all the time, Bluebird works great! Are all these BC breaks really just to avoid
require('bluebird').promisifyAll(...)? I feel like I must be missing something cuz this seems like a lot of squeeze for very little juice.
From the non-core-dev peanut gallery: please don't make node core chase the latest API. The wild mix of approaches to handling async flow control exist because core doesn't pick a solution. Promises themselves have evolved quite a bit since Futures/Defereds hit the scene. If core had settled on the prevailing API of the the time (jquery/Q.deferred or whatever), a lot of this evolution might not have happened. 👍 promises 👎 promisifying core.
Edit: Is there a "workaday developer advocate" or something for Node.js? I see language authors, transpiler authors, etc., discussing whether to add a new API to node core, meanwhile the average developer's head is spinning trying to keep abreast of all the existing changes.
Are people hearing "I wish the JS ecosystem had more frequent major changes; the JS ecosystem just moves so slow!" from the community? Because that's the opposite of what I hear.
I hope the Thought Leaders & top .1% JS devs are taking the experiences of the average developer into account when considering changes like this. "Can a transpiler author understand it" is not a test for deciding whether something will confuse a lot of developers. I'm not saying design to the lowest common denominator, just that "how will this change impact the average developer" should be a major consideration.