Re: [w3ctag/design-reviews] <link> rel="modulepreload" (#213)

Hi,

@irori, @domenic, @nyaxt and @kinu met and briefly discussed this issue. We see that there’s been some confusion, and would like to explain the current shape of the API better. We hope that this also helps future API exploration in this area.

## Clarification of the current API shape

First of all, `link rel=”modulepreload”` in the current shape does a combination of the following:

* Declarative fetch (preload), with a change in cors fetch mode (always cors)
* Module map population
* Optional recursion (which allows optional instantiation)

The tone of the [original explainer](https://docs.google.com/document/d/1WebH4IOCswACUbaczx5cGQPVl5mnqcieOd4MRJM2syk/edit) and the name `modulepreload` might have been a bit misleading, but it’s rather a high-layer API that does multiple things that would be most commonly needed for better perf in modules loading than a low-layer fetch/preload primitive. (The *most commonly needed* part is an assumption, and we will / hope to have more insights)

This clarification gives some implication that adding a generic option like `includeDependencies` to `preload` could make the layering discussion more complicated. For example it was mentioned that CSS fetching could be done in a similar way, but if we take a closer look it’ll also need to do multiple things, e.g.:

* Declarative fetch
* CSS parsing and style stuff
* Optional recursion
* (... maybe other stuff ...)

And mechanically extracting the first and third bits (i.e. fetch and recursion) may not make a lot sense.

Also to clarify: we didn’t implement the recursive fetching part and we don’t think it should be mandatory.  Rather it should be phrased like: “UA is *allowed* to perform recursive fetch”.  This is because making it mandatory could easily introduce O(N^2) explosion, and developers tend to explicitly write out modulepreload for recursive resources flatly anyway.

## Potential lower-layer primitives

As mentioned earlier the current `modulepreload` is structured as a high-level API that does multiple things.  This API can probably be decomposed in the following way:

```javascript
let responsePromise = fetch("module.mjs");
let parsed = new JSModuleAST(); // or OpaqueModuleHandle
await parsed.replace(responsePromise);
self.moduleMap.set("module.mjs", parsed);
const urls = parsed.imports;
```

WebASM is doing something similar (afawk), and for CSS the similar space is being explored with constructible stylesheets. We think this direction would be worth exploring (maybe in conjunction with Preload/Loading worklet like approach) if we start to see stronger use cases (implying, the authors didn’t take this approach due to lack of strong use cases compared to the necessary amount of work). We hope that we get more feedback/insights in this area based on the current API.

## AIs:
Here are the AIs (in addition to leaving open discussion for lower-layer explorations) we can do:
* @irori will update the explainer to reflect the latest API clarification, impl status and discussion
* @domenic will update the spec to add an explicit note about the current implementation status about recursion, to call for further impl/spec feedback

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/213#issuecomment-447735013