Estimate on when the v8 that has native Promises will land in Node.js?

180 views
Skip to first unread message

CoolAJ86

unread,
Jun 2, 2014, 1:54:06 PM6/2/14
to nod...@googlegroups.com
I'm so glad that we're at the cusp of finally putting all this Promise nonsense to bed (I just wish they had made event emitter native too), but after 6 months since being added to v8, Node still doesn't have legit JavaScript(tm) native Promises... does anyone have an estimate on when that will land?

I'm anxiously looking forward to the day when we can start putting in bug requests and patches on every package that uses one of the 20,000 promise libraries (including many of my own).

Forrest Norvell

unread,
Jun 2, 2014, 10:31:34 PM6/2/14
to nod...@googlegroups.com
On Mon, Jun 2, 2014 at 10:54 AM, CoolAJ86 <cool...@gmail.com> wrote:
I'm so glad that we're at the cusp of finally putting all this Promise nonsense to bed (I just wish they had made event emitter native too), but after 6 months since being added to v8, Node still doesn't have legit JavaScript(tm) native Promises... does anyone have an estimate on when that will land?

Unless there's a rollback to a pre-3.25 version of V8 in Node 0.11.14 (very unlikely), Promises will be available in Node 0.12 without the use of a command-line flag. HOWEVER! V8's Promise implementation has a couple significant bugs and should NOT be considered ES6-compliant. I personally would not rely upon them, and would stick with Q, Bluebird, or another better-tested implementation that was designed to be used with Node.

I'm anxiously looking forward to the day when we can start putting in bug requests and patches on every package that uses one of the 20,000 promise libraries (including many of my own).

I don't really get this. As long as the promises implementation is Promises/A+-compliant, who cares which implementation it uses? Different implementations specialize in different things (simplicity, interoperability with Node's callback APIs, performance), so why would you want everyone to be using the same implementation?

F

Floby

unread,
Jun 3, 2014, 5:00:14 AM6/3/14
to nod...@googlegroups.com
Moreover, if you're gonna spam every single module author with pull request on things that work, you're not gonna make many friends.

Current promises libraries work and are well tested. A native implementation would perhaps yield better performance, but it would be mostly unstable for a few months. If you need performance, well, don't use promises ? :)
Reply all
Reply to author
Forward
0 new messages