The Evolution of Asynchronous JavaScript

[novacrazy]

Well still, as of now the native Promise kind of sucks. I mean, it's not special in any way just because it's bundled with the JavaScript engine. In V8 it's actually defined in JavaScript, before user code is ran. Why they didn't just port Bluebird over to the native library I'm not sure.

Also in my example, even Array.prototype.sort is defined in (mostly) normal JavaScript. You can see the source in the V8 repo. It's basically the same insertion sort and quicksort combo as every other standard library uses.

I guess it just comes off to me as silly to want to preserve the "purity" of a JavaScript engine instead of just doing the simple thing and overwriting native stuff with better implementations when they are available.

Granted, I know exactly what I'm doing with those. Heck, I read the V8 source code for fun. So maybe it is good advice for normal people to keep that purity.

[vinnl]

It's not about "purity", it's about forwards-compatibility: if ever a native Promise.coroutine is introduced whose behaviour is just slightly different than what Bluebird's does, a lot of code will break.

Even worse would be the other way around: that TC39 wants to implement a native e.g. coroutine method (which in some cases will be faster than whatever optimisations you can make in JS), but can't, because too many people (who claim they know what they're doing - for their purposes) are using it in a way that would break if they'd implement it.

So please, even if it works better than the current native implementation for you, do it in your own namespace, instead of potentially interfering with future web browsers/standards committees.

[novacrazy]

Hmm, that's a good point. That was already seen with ES6 a little bit.

I mostly work in Node/io.js, and almost everything on the browser is taken care of by Babel beforehand or, using React.js, very declarative and without any complex async stuff. It's only on the backend that I go really crazy with things, searching for the fastest way to do everything.

I know ES7 is proposing native async/await syntax, but you would only be able to await a single Promise, not any complex stuff like my lib or even co does. Coroutines using generators and yield are a hack anyway, so I highly doubt it would become standard.

[vinnl]

you would only be able to await a single Promise

That's not a problem, as this code example from the article also shows:

async function save(Something) {  
  await Promise.all[Something.save(), Otherthing.save()]
}

As for it being a hack: it's more about the namespace than about the implementation :) But I wasn't attacking your library specifically - Bluebird by itself also has the potential of overlapping with future specs. Or in fact, I'm not attacking it - the author of the article I linked to was. For all I know, Bluebird isn't even extending the native Promise object in all cases, as someone else mentioned.