es6 polyfill?

[jonathanong]

there's https://github.com/jakearchibald/es6-promise but i don't really want to use it because it's based off of rsvp.js.

[petkaantonov]

var Promise = require("bluebird");
Promise.onPossiblyUnhandledRejection(null);
var es6methods = ["then", "catch", "constructor"];
var es6StaticMethods = ["all", "race"];

function isNotMethod(name) {
    return !(es6methods.indexOf(name) >= 0 ||
           es6StaticMethods.indexOf(name) >= 0 ||
           name.charAt(0) === "_");
}

function del(obj) {
    return function(key){ delete obj[key] }
}

function toFastProperties(obj) {
      (function(){}).prototype = obj;
}

Object.keys(Promise.prototype).filter(isNotMethod).forEach(del(Promise.prototype));
Object.keys(Promise).filter(isNotMethod).forEach(del(Promise));
toFastProperties(Promise);
toFastProperties(Promise.prototype);

[jonathanong]

haha nice. would be nice as a build or at least a file in the repo.

[petkaantonov]

It was a joke, if you want to stick to the es6-subset, then stick to it - no code necessary. Although you will still need to call Promise.onPossiblyUnhandledRejection(null); to replicate the authentic debugging hell that es6 shim would provide.

[danielkcz]

Here goes fresh polyfill by @getify.

Maybe bluebird could use ES6 promises internally instead of custom implementation? It would be probably even faster. Currently I am using bluebird mainly because bunch of useful utility functions and superior error handling. I would like to keep that.

Bluebird could allow to optionally extend native Promise object when the one is found instead of making own one? That way the utility functions will be there together with faster implementation of Promise.

Hope it makes some sense, it's somewhat hard to explain for me :)

[petkaantonov]

If you want performance you can keep using bluebird till the end of the times, native will never beat it.

[stefanpenner]

@FredyC lots of the performance of utilities comes from them having access to internals which native promises don't expose.

[danielkcz]

@petkaantonov How come? I wasn't examining it closely and I am not really sure about differences, but isn't usually native code faster than interpreted one?

@stefanpenner I see, that makes sense.

[petkaantonov]

@FredyC 10 years ago called, they want their interpreters back

[petkaantonov]

angular/angular.js#6697 (comment)

[danielkcz]

@petkaantonov Awesome, so it's great I have picked bluebird. Thanks :)

[mjackson]

@petkaantonov It would be really nice to be able to require a file that only has the es6 subset of methods so the whole library doesn't get included in my Browserify build. Is that possible?

[phpnode]

@mjackson such a thing would not be bluebird, why do you want that? To shave a few bytes?

[mjackson]

To shave a few bytes?

Yes. More than a few.

[benjamingr]

What about using a partial build?

On 28 באוג׳ 2014, at 21:10, Michael Jackson notifications@github.com wrote:

To shave a few bytes?

Yes. More than a few.

—
Reply to this email directly or view it on GitHub.

[getify]

@mjackson if file-size (and standards compliance) are the main concerns, just try my 1.3k native-promise-only polyfill, as mentioned above. :)

[benjamingr]

NPO doesn't have global unhandled rejection handling (yet!!), switching to it in production might be an option for you but personally I find the unhandled rejection tracking the most useful in production.

On 28 באוג׳ 2014, at 21:26, Kyle Simpson notifications@github.com wrote:

@mjackson if file-size (and standards compliance) are the main concerns, just try my 1.3k native-promise-only polyfill, as mentioned above. :)

—
Reply to this email directly or view it on GitHub.

[getify]

@benjamingr that's true, researching adding that behavior for the debug version of NPO. it's got some trickiness, but I think it might work. but then again, NPO's goal is to stick to the spec, so that's why I said "and standards compliance". :)