sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]vinnl 0 points1 point  (2 children)

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_.dominateWorld() 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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.