v1: executing async functions without callbacks should return promises

[jonathanong]

now that Promises are included in master, how about having async functions returning promises when no callback is supplied? this semi-breaks backwards compatibility, but people should be passing callbacks right now anyways, even just noops.

i think this belongs in v1, but 0.14 would be great as well. we could add a note to "always add callbacks!" for migration

[trevnorris]

Nope. First, v8's native Promise implementation is borked. Second, Promises won't become part of Node's native API. It'd difficult enough having callbacks, event emitters, streams, etc. Node needs to simplify, not expand, so that users can create better interfaces that use whatever your heart desires (e.g. Promises, generators, etc.)

@domenic I know you'll have an opinion on this. ;-)

[jonathanong]

okay. i don't disagree because i don't even understand promises. haha.

it would be nice to have an "official roadmap" for es6 and beyond just so we know.

[domenic]

I think Node will need to adopt promises (in core, not "make users do it") if it wants to stay relevant. But @trevnorris and I have talked earlier about a path toward this, of simplifying the libuv -> C++ wrapper -> JS layers, that would allow promises to be introduced more easily. And that plan seems like a very good one.

And yes, V8's promises have a lot of nonstandard methods and at least one flat-out bug :(

[Fishrock123]

+1 for an official ES6 roadmap of sorts.

[tjfontaine]

Node will continue to be vanilla javascript (that is to say pre-es6) for the short and medium term, especially as people are able to make promises work with Node API's without Node having to do anything to accommodate that.

The fact that Promises exist in newer versions of Node is merely an implementation detail of Node using v8 as its current runtime and not an indication of a decision on the roadmap for Node's future usage concerning control flow, or any other ES6 feature.

[petkaantonov]

It'd difficult enough having callbacks, event emitters, streams, etc.

I know what you mean but still, only straight callbacks are mutually exclusive (As in it doesn't make any sense to use one if you are using another) with promises, the others are orthogonal and have different use cases. There isn't even supposed to be "x all the things" where x is some hammer like event emitter, stream, callback or promise.

[Raynos]

-1 on promises.

Callbacks are a feature, if the node APIs were promise based they would be less useful.

Currently node throws programmer errors on invalid usage and returns operational errors in the callback. Promises don't have a good story for separating operational & programmer errors.

[jquense]

+1 for some es6 clarity and road map. there is a vibe that the node community decided that es6 is not 'real js' I agree with @domenic that node isn't going to stay relevant if it's permanently hitched to an old version of the language, especially when browsers have moved on. that said this is a challenging thing to get right that doesn't face other platforms :/ so caution is appreciated, certainly let since v8 features are ready yet.

as a side point I disagree with @Raynos, I think promise error handling is muuuuch saner. but I had never thought about callback errors as a feature. really interesting perspective :) , tho I think I'd still rather have my errors work like every other platform; exceptions are thrown and caught

[benjamingr]

@Raynos "If the node APIs were promise based they would be less useful" is just FUD, especially since exporting a callback API from a promise one is trivial.

Although in all fairness, I agree that this should be postponed for at least until v8 stable promises land.

[tjwebb]

Node will continue to be vanilla javascript (that is to say pre-es6)

When es6 is ratified, it will simply be known as "Javascript". es6 will be the new "vanilla". es5 will be "legacy", and so will node.js if that's the sole inspiration for the API.

The fact that Promises exist in newer versions of Node is merely an implementation detail

To the degree they are adopted as convention in Javascript projects and frameworks, node's lack of Promise usage will be conspicuous, at odds with what JS developers expect, and lend more legitimacy and momentum to forks such as io.js.

node.js's refusal to offer a clear roadmap does not inspire trust in the community. As a node.js developer, I find @tjfontaine's comment somewhat demoralizing.

[domenic]

When es6 is ratified

This is not a useful benchmark. Implementation progress is what matters. Spec versions are a fiction. (I say this as a TC39 member.)

[tjwebb]

There are already partial implementations, and surely by EOY some of them will be downright usable :) Point taken, but I'm pointing out that the ratification milestone itself is just a necessary step of a process that is already occurring -- that these are the features developers are going to expect from the engines. Once the corpus of code is built up and collective experience is gained with the new spec, it will be the Javascript.

[jasnell]

A clear roadmap for ES6 support would definitely be welcome (specifically something that documents how and when a particular feature/standard would be considered for support in node), but I would agree that full ES6 support is certainly not on the priority list for getting to a 1.0 release, especially since (as @tjfontaine points out) those bits can be quite effectively polyfilled (https://www.npmjs.com/search?q=ES6).

[g13013]

@Raynos seriously ?

[flying-sheep]

OK, so mz gives use a third-party module offering e.g. a promisified fs. it allows (via any-promise) to use e.g. bluebird if native promises are too slow for your tastes.

i think node should finally offer promisified APIs. probably in concert with a way to register the promise implementation to use.

execution flow is simply much clearer when using promises. take e.g. this function: the use of Promise.all allows to very easily perform asynchronous action in parallel and synchronize at easy to see points.

---

@Raynos point is also obviously invalid: a programmer error will make the function throw an error instead of returning a promise, while an operational error can be handled with catch, or by separating promise creation and resolution:

let p = null
try {
    p = doSomethingAsync()
} catch (imStupid) { … }
try {
    await p
} catch (theWorldIsStupid) { … }

[Fishrock123]

Please point this to https://github.com/nodejs/node, it unlikely to get further attention here.

There have been several issue opened on the new issue, I'm sure you can find them if you look.

[flying-sheep]

ah, thanks. didn’t check the repo name as i was linked here from some other discussion