-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introducing Promises to node core? #4596
Comments
One of my main concerns with adding support for (standard) Promises is performance. My other major concern is backwards compatibility issues (including the examples you touched on) and the option to still use callbacks. With regard to the "browsers are doing it" argument, IMHO that doesn't really matter because node isn't a browser and as such doesn't have a DOM or any of the other browser-specific things you mentioned. Also, votes for a random twitter poll that is less than a day old is hardly representative of the node.js community/ecosystem. FWIW previous discussion on this matter can be found here. |
Discussion around this is probably better suited to the existing Promise issue over in the |
Also see #11. I'm going to close this as a duplicate of #11 and in favor of nodejs/NG#25. |
Thanks for the reference to nodejs/NG#25. I'll move the discussion to there. |
It looks like in Node.js version 9, Promises were added to core? At least for fs? |
anyone? |
@ORESoftware I am not sure where you got that info from. The pull request to add that is still open and WIP. If you need to find information about features, please check the changelog and the public API documentation. You will find everything published in those places. |
Yeah I can't remember, I caught wind of it about 3 or 4 weeks ago |
@BridgeAR can you give link to that PR? For when are the plans to be released, v10? |
#18297 landed three days ago on master. |
Even though Promises were removed back in the early days, the situation has changed. I propose we re-introduce Promises to Node.js, (mostly) without introducing breaking changes.
async
/await
)fetch
, ServiceWorker, etc.Encouraging Use of Promises
ES6 in and out of itself is encouraging more and more developers to use promises, and if Node.js were to add support for promises that'd send a clear signal to the community that promises have widespread support.
I understand most noders prefer callbacks, as I used to (now I don't mind either way). However, they're not that terrible to work with if you're familiarized with them. In addition, promises now being part of the language means more libraries leveraging and written around promises.
As a Breaking Change
This change would break shorthand notation where people write code like this, although in these situations people hardly ever use the return value of
foo
.That being said it's a very real possibility that introducing a Promise result to callback-based APIs where no responses were assumed could signify a breaking change in cases where poor coding practices are followed.
Scope
While all of the modules below offer callback-based APIs, it wouldn't be that hard to provide promise based APIs for most of these. Particularly because most promise-based methods could be a wrapper around the callback-based API.
readline
methods offering a callbackrepl
methods offering a callbackfs
methods offering a callbackutil
methods offering a callbackcrypto
methods offering a callbackzlip
methods offering a callbackchild_process
methods offering a callbackcluster
methods offering a callbackprocess
methods offering a callbackhttp
methods offering a callbackhttps
methods offering a callbacknet
methods offering a callbacktls
methods offering a callbackdgram
methods offering a callbackdns
methods offering a callbackstream
methods offering a callbackObviously, the implementation wouldn't have to offer every single callback-based method in a promise-based flavor. For instance, it could start with just
fs
methods.The text was updated successfully, but these errors were encountered: