#334: HTML Modules

Visit on Github.

Opened Jan 16, 2019

こんにちはTAG！

I'm requesting a TAG review of:

  • Name: HTML Modules
  • Explainer doc, Code example
    • For those interested in further details, this design doc has specifics on how we would propose to implement this feature in Chromium.
  • Specification URL: pending
  • Tests: pending submission
  • Primary contacts: @dandclark, @samsebree, @travisleithead, @BoCupp-Microsoft

Further details (optional):

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our Github repo for each point of feedback
  • open a single issue in our Github repo for the entire review
  • leave review feedback as a comment in this issue and @-notify @dandclark @samsebree @travisleithead @BoCupp-Microsoft

Discussions

Comment by @kenchris Jan 22, 2019 (See Github)

@dandclark @samsebree @travisleithead @BoCupp-Microsoft

First of all, I really welcome this feature and the great detailed explainer.

In the line of, now postponed declarative shadow dom, I believe HTML modules to become popular by designers etc, at least if they can stay within the realm of HTML and CSS and thus avoid "coding" JavaScript. I think it is valid to consider this case and I see that there is already an issue filed about a declarative way to export (https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/9).

As you allow multiple exports (like ECMAScript Modules), this makes it a valid target for dead "code" elimination and "code" splitting (dead content elimination and content splitting? :-)) - I don't know what is needed to make that work well, but I believe it is important to consider, especially because if it is not possible, you will see developers arguing for just using scripts instead (CSS-in-JS etc)

Comment by @cynthia Jan 22, 2019 (See Github)

This has been brought up here but it really feels like non-script use cases should be covered.

Another thing that came to mind is how this would work in a non-web context (e.g. node.js) since module support is a feature there, and would be a bit hard to implement as a third-party library.

(That said, I really like this feature.)

Comment by @travisleithead Jan 29, 2019 (See Github)

As you allow multiple exports (like ECMAScript Modules), this makes it a valid target for dead "code" elimination and "code" splitting (dead content elimination and content splitting?

I'm not sure I understand what you mean here, can you clarify (perhaps with an example)?

Comment by @kenchris Jan 30, 2019 (See Github) 
<!doctype html>
<html>
<template id="one">
  ...
</template>

<template id="two">
  ...
</template>
<script type=module>
   const one = import.meta.document.getElementById("one");
   const two =  import.meta.document.getElementById("two");

  export { one, two }
</script>
</html>

   <!doctype html>
<html>
    <head>
        <title>HTML Modules Demo</title>
        <script type="module">
            import { one } from "./one-and-two.html";
            // do stuff with 'one', but never import and use 'two'
        </script>
    </head>
    <body>
        ...
    </body>
</html>

As I am only using the 'one' template, tooling should be able to treeshake and provide the first time as just containing 'one' given that I never use 'two' in the project. This is commonly done in JS today with tools like WebPack, and it is important that we don't do anything making it impossible or hard to treeshake or to dead code elimination

Comment by @matthew-dean May 10, 2019 (See Github)

I do hope that import {foo} from 'bar.html' never actually happens. Markup should be included via markup. JS should be imported via JS.

Comment by @kenchris Sep 10, 2019 (See Github)

As far as I was told, the current focus is on first doing JSON modules, then CSS modules and then revisit HTML modules. So we are changing progress to stalled until work re-starts on HTML modules. When that happens, please ping us here

Discussed Jun 1, 2020 (See Github)

Tess: I think we should just close this. Work on HTML modules is pending on the issues TC39 is working on, ES module attributes I think was the name. We should close for now with a note to come back once ready.

Rossen: All modules or HTML only?

Tess: We're talking about HTML modules at the moment.

Rossen: Right, but there's no reason to keep CSS and JSON modules if this one closes.

Tess: They're both already closed.

Peter: I'm fine closing with the note.

Tess: Great, I'll write the note.

Comment by @hober Jun 10, 2020 (See Github)

Since HTML Modules (like CSS and JSON Modules) is waiting on tc39/proposal-import-attributes to advance, we're going to close this review for now. Please file a new one or have us re-open this one once HTML Modules is un-blocked. Thanks!

Comment by @o-t-w Aug 28, 2023 (See Github)

tc39/proposal-import-attributes no longer blocks this.

Discussed Jan 1, 2024 (See Github)

reassigned to Lea & Tess

Comment by @sashafirsov Feb 6, 2024 (See Github)

As been mentioned by HTML modules - problem statement , There are a number of issues with that proposal. One big one is that you can't define exports without using script. Its design seems to not consider the possibility of a DCE.

The pure declarative implementation can rely completely on referencing the template( or any another element) DOM subtree. Same is applicable when importing from JS. Such approach is working for declarative and JS use. Samples in DCE POC: https://unpkg.com/@epa-wg/custom-element@0.0.14/demo/external-template.html