3 ms·
I would recommend not doing that. The script tag is always bound to the load event. If the payload is huge the load event will wait for download. The async a
by austincheney 8y ago
I would recommend not doing that. The script tag is always bound to the load event. If the payload is huge the load event will wait for download. The async attribute merely tells the browser to execute the script contents asynchronously if properly supported and if fetched as a file from a src attribute.
A more stable approach is to put the code within a timer. This covers all use cases and is universally supported since nearly forever. Example:
let myCode = function () {};
setTimeout(myCode, 1);
Or
setTimeout(function () {}, 1);
Either way you are still stuck with network resolution of the script tag contents.
- jhabdas 8y agoAssuming apps composed of light weight micro-libs I tend to find apps: 1) Miss taking advantage of browser capability to parallelize downloads, leading to lost real time in most browsing contexts. 2) Make it difficult if not practically impossible to leverage before domready cycles in the event loop. Is it stable to detatch from the load event in the case script is not the initiatitor? Yes, unless one can reasonably expect document body to close (no more writes) at some real time after external downloads complete. But that potential pitfall, in any case, can be controlled with a deferred bound to the domready event. What I have witnessed, however, is the browser tends to do a better job optimizing for scripts loaded over HTTPS in a way fetch cannot when controlled by the implementation.