HTML Modules - Githubissues

dandclark commented 5 years ago

こんにちは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):

Relevant time constraints or deadlines: None
[x] I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
[x] I have reviewed the TAG's API Design Principles

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
[x] leave review feedback as a comment in this issue and @-notify @dandclark @samsebree @travisleithead @BoCupp-Microsoft

kenchris commented 5 years ago

@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)

cynthia commented 5 years ago

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.)

travisleithead commented 5 years ago

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)?

kenchris commented 5 years ago

<!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

matthew-dean commented 5 years ago

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

kenchris commented 5 years ago

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

hober commented 4 years ago

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!

o-t-w commented 1 year ago

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

sashafirsov commented 9 months ago

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

w3ctag / design-reviews

HTML Modules #334