Skip to content
This repository has been archived by the owner on Jul 13, 2020. It is now read-only.

When doesn't respect the native Promise implementation. #338

Closed
fd opened this issue Mar 26, 2015 · 6 comments
Closed

When doesn't respect the native Promise implementation. #338

fd opened this issue Mar 26, 2015 · 6 comments

Comments

@fd
Copy link

fd commented Mar 26, 2015

See: cujojs/when#442

@guybedford
Copy link
Member

When I last tested (although quite a few months ago now), When was actually still much faster than native promises, making this a good thing.

We do have builds without the promise implementation though if this is needed, see https://github.com/ModuleLoader/es6-module-loader/blob/master/dist/es6-module-loader-sans-promises.js.

@fd
Copy link
Author

fd commented Mar 26, 2015

The reason I want native Promise when available is so that Chrome can help debugging them. (with their new Promise inspection panel)

Would it be possible to use when just in es6-module-loader internally.

@guybedford
Copy link
Member

Is there a reason you can't just use the sans-promises build here?

@fd
Copy link
Author

fd commented Mar 26, 2015

I don't like swapping out dependencies based on development/production differences.

As for the performance problems. Eventually native should always be faster than any JS polyfill. So having a slow Promise for 18 weeks (three release cycles in Chrome/FF) seems reasonable. Also browser vendors that refuse to improve their implementations should not be let off the hook that easily (looks at Safari/Mobile Safari for not having a proper release schedule).

On the other hand I do understand the desire to have everything work perfectly everywhere.

Note: 18 weeks to move from canary/nightly to stable.

@guybedford
Copy link
Member

@fd you can use the sans-promises entirely for both dev and production.

@fd
Copy link
Author

fd commented Mar 26, 2015

@guybedford sure that's true.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants