Open msaspence opened 8 years ago
First up, I love the idea of removing the hassle around timing something. My immediate reaction to this was around promises requiring a polyfill. I wonder how small a Promises polyfill is... If it's not an order of "tiny", I wonder if it'd be best to add features like this asynchronously after the page has loaded. We need the core script to load first to ensure we get page events before everyone else, I guess that doesn't mean we have to actually do anything else at that point.
Yeah I also think the idea of a "two stage load" is interesting. I wonder if there is anything currently in the core script that could be moved into a subsequent phase?
I'm actually really impressed at how far UglifyJS
and JSCrush
can compress code, we might get away with more than I expect. Promises aside, this is worth implementing as usual. How about we only support Promises if they're supported natively?
Yes but rather than saying "are these supported natively" can we duck type the returned value. i.e. if it exposes a promise like interface, we will treat it as such, this allows the application to load its own polyfill for Promises before any calls to timer
. If the calling code is returning a promise and either the browser doesn't Promises or they have loaded a polyfil we don't have to worry.
Something like: