Add some examples

[domenic]

The current readme doesn't really help people understand what this is actually about at a glance; they have to read the whole thing.

I tried this briefly but my examples became a bit too large. Probably if I try again on a fresh day it'll be fine. But contributions from others would certainly be appreciated too.

[matthewp]

Some use-cases for this include:

• Language packs (alluded to already).
• Lazy-loading resources upon navigation.
• Loading environment-specific resources.

[matthewp]

My first take at the lazy-loading scenario:

<nav>
  <a href="page1.html" data-bundle="page-one">Page One</a>
  <a href="page2.html" data-bundle="page-two">Page Two</a>
  <a href="page3.html" data-bundle="page-three">Page Three</a>
</nav>

document.querySelector('nav').addEventListener('click', e => {
  e.preventDefault();

  await import(`./bundles/${e.target.dataset.bundle}.js`);
});

[probins]

this example is very similar to the fetch-text example on https://github.com/mdn/fetch-examples/. What's the advantage of using import() for this sort of thing?

Could import() be used to help integrate JS modules/web components? Something like:

import('https://elements.cdn/specialElementClass.js')
.then(... customElements.define("special-element", module); ...

[domenic]

Well, in this example we're fetching a JS module with exports, not just text.

Could import() be used to help integrate JS modules/web components? Something like:

It could, but this doesn't really demonstrate any advantages of doing this dynamically, instead of just using <script type="module">

[probins]

yes, but why have a module just to load an HTML page/fragment? I suppose it depends on what loadPageInto in the Readme example actually does. If it's something complicated rather than a simple copy/clone of HTML, then I suppose the module is more like a component which defines behaviour as well as content - which brings me nicely back to my other question. :-)

Examples of dynamic loading and run-time conditions:

• if queryparam (in browser) or cli option (in Node) import('a') else import('b')
• if browser doesn't support x, import('polyfillforx')

General principle: only load what the user needs when they need it.

[matthewp]

if queryparam (in browser) or cli option (in Node) import('a') else import('b')

This isn't really an example though. What use-case are you thinking of?

if browser doesn't support x, import('polyfillforx')

Yeah, polyfills are a good one.

[domenic]

Polyfills are only reasonable if you plan to not use the feature until the polyfill is done loading, which I haven't seen too much of...

[ljharb]

Typically polyfills need to be synchronous, and to block other code, for the exact reason @domenic mentions.

[probins]

if browser doesn't support x, import('polyfillforx').then(import('codewhichusesx') ?

[domenic]

Yes. I've never seen code like that in the wild using existing script-loading techniques, so I am not really excited about including it, as it will seem like a weak example.

[probins]

yeah, you're probably right

[probins]

on the runtime params, my main use case is a map (as in geography) app where what is loaded/displayed is entirely runtime determined, for example by querystring params or by users selecting from lists; the default is a blank canvas. That's not a simple example though. Perhaps a small example would be that if the browser supports WebGL, then import the code that uses that, otherwise import code that uses Canvas.

[probins]

just to clarify that I've understood correctly: in the Readme example, ./section-modules/ is relative to the importing script, right? So if this were loaded with <script src="https://cdn.com/importingScript.js">, then ./section-modules/ would be https:/cdn.com/section-modules/?

[domenic]

Correct.

[hax]

Ideally polyfills need to be synchronous, but actually we don't have the feature which could conditionally load polyfills synchronous. So I think if (!supportFeatureXXX) import('polyfillForXXX') is still a valid use case.

[sashafirsov]

@hax , the polyfills do not need to be synchronous as long as they are listed as dependencies within the module or module alias( artificial module with only purpose of filling the polyfills returning the original content).

[ljharb]

To clarify, it's not that polyfills need to be synchronous, it's that they need to be able to guarantee execution before any other code runs.