4 ms·

This looks like the perfect case for using Promises... loadjs('foobar').then(() => { // foobar.js loaded }); And then with the newer spec:

This looks like the perfect case for using Promises... loadjs('foobar').then(() => { // foobar.js loaded }); And then with the newer spec: await loadjs('foobar'); // foobar.js loaded Such a pity that instead it uses a proprietary format. Edit: you could still add all other nice things without compromising the main thing, for example to add a "before": loadjs.before(fnA).before(fnB).load('foobar').then(() => {});

inglor 10y ago
Also, it's a spec in the making `System.import('foobar')` only that actually works with modules rather than scripts.
thomasfoster96 10y ago
Someone please correct me if I’m wrong, but I’m pretty sure await has to be within an async function [0]. [0] https://github.com/tc39/ecmascript-asyncawait/issues/36 https://github.com/tc39/ecmascript-asyncawait/issues/36
- Klathmon 10y ago
  Yeah but we can use the same "trick" we've been using for years, an IIFE: (async () => { // Code... })()
  - denisw 10y ago
    This will wait within the function, but won't block the caller.
    - Klathmon 10y ago
      which is what it should do If you want the caller to "block", then it needs to await or .then() what it's calling.
xatxat 10y ago
Checkout the import() proposal: https://github.com/tc39/proposal-dynamic-import https://github.com/tc39/proposal-dynamic-import It basicly is what you are describing.
robocat 10y ago
> This looks like the perfect case for using Promises... I think promises are a bad idea if loading JavaScript is on the critical path to rendering your page. Unless you have so much JavaScript that parsing takes a long time and you need to yield to the layout and composition engine... I wrote my own bundle loader so that: * cached JavaScript loads fast * CSS is put into a JavaScript string and loaded as a JavaScript file so (1) success and error handling code is simplified and (2) because error handling for CSS is hard -- e.g mycss.js looks like insertCssStyle('.much {css: here}'); * Small images are compiled into the CSS as data. Fonts are loaded in the CSS as data (avoiding a couple of bugs). * it starts loading in <head> (avoiding much delay). * It inserts <script> elements (rather than use XHR and eval) so that stack traces are readable, and cross origin works well, and so the browser can multithread the loading and parsing. * it requests scripts from a single cross origin cloudflare host (for speed and caching), but re-requests from the page's domain if that isn't working (for reliability). * loading failures are logged to third party (for checking reliability). * JavaScript bundles are wrapped in try/catch for logging, and they explicitly call a function too indicate the bundle loaded successfully (and to chain dependencies correctly for async loading). It is hard to make a single page app load reliably, and to report failures correctly if it fails!
pygy_ 10y ago
Promises are actually bad for that use case because you want the completion callback to run synchronously on load, otherwise, foreign code may trample a global between the time the script loads and the time the 'loaded' function runs. This may not be an issue with native ES6 Promises (since they rely on microtasks) but other implementations/polyfills may not be airtight (setTimeout-based ones aren't for sure, for example).

inglor 10y ago

Also, it's a spec in the making `System.import('foobar')` only that actually works with modules rather than scripts.

thomasfoster96 10y ago

Someone please correct me if I’m wrong, but I’m pretty sure await has to be within an async function [0]. [0] https://github.com/tc39/ecmascript-asyncawait/issues/36 https://github.com/tc39/ecmascript-asyncawait/issues/36

Klathmon 10y ago
Yeah but we can use the same "trick" we've been using for years, an IIFE: (async () => { // Code... })()
- denisw 10y ago
  This will wait within the function, but won't block the caller.
  - Klathmon 10y ago
    which is what it should do If you want the caller to "block", then it needs to await or .then() what it's calling.

xatxat 10y ago

Checkout the import() proposal: https://github.com/tc39/proposal-dynamic-import https://github.com/tc39/proposal-dynamic-import It basicly is what you are describing.

robocat 10y ago

> This looks like the perfect case for using Promises... I think promises are a bad idea if loading JavaScript is on the critical path to rendering your page. Unless you have so much JavaScript that parsing takes a long time and you need to yield to the layout and composition engine... I wrote my own bundle loader so that: * cached JavaScript loads fast * CSS is put into a JavaScript string and loaded as a JavaScript file so (1) success and error handling code is simplified and (2) because error handling for CSS is hard -- e.g mycss.js looks like insertCssStyle('.much {css: here}'); * Small images are compiled into the CSS as data. Fonts are loaded in the CSS as data (avoiding a couple of bugs). * it starts loading in <head> (avoiding much delay). * It inserts <script> elements (rather than use XHR and eval) so that stack traces are readable, and cross origin works well, and so the browser can multithread the loading and parsing. * it requests scripts from a single cross origin cloudflare host (for speed and caching), but re-requests from the page's domain if that isn't working (for reliability). * loading failures are logged to third party (for checking reliability). * JavaScript bundles are wrapped in try/catch for logging, and they explicitly call a function too indicate the bundle loaded successfully (and to chain dependencies correctly for async loading). It is hard to make a single page app load reliably, and to report failures correctly if it fails!

pygy_ 10y ago

Promises are actually bad for that use case because you want the completion callback to run synchronously on load, otherwise, foreign code may trample a global between the time the script loads and the time the 'loaded' function runs. This may not be an issue with native ES6 Promises (since they rely on microtasks) but other implementations/polyfills may not be airtight (setTimeout-based ones aren't for sure, for example).