Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTML Modules #334

Open
3 of 5 tasks
dandclark opened this issue Jan 16, 2019 · 9 comments
Open
3 of 5 tasks

HTML Modules #334

dandclark opened this issue Jan 16, 2019 · 9 comments
Assignees
Labels
Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review Progress: stalled Review type: CG early review An early review of general direction from a Community Group Topic: components Topic: HTML Topic: modules

Comments

@dandclark
Copy link

dandclark commented Jan 16, 2019

こんにちはTAG!

I'm requesting a TAG review of:

Further details (optional):

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

@kenchris kenchris self-assigned this Jan 17, 2019
@kenchris
Copy link

kenchris commented Jan 22, 2019

@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 (MicrosoftEdge/MSEdgeExplainers#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
Copy link
Member

cynthia commented Jan 22, 2019

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

@kenchris kenchris pinned this issue Jan 22, 2019
@kenchris kenchris unpinned this issue Jan 22, 2019
@travisleithead
Copy link
Contributor

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
Copy link

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

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
Copy link

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

@kenchris kenchris added the Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review label Dec 4, 2019
@alice alice removed this from the 2019-06-12-telecon milestone Jan 27, 2020
@cynthia cynthia added this to the 2020-06-08-week milestone May 27, 2020
@hober
Copy link
Contributor

hober commented Jun 10, 2020

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!

@hober hober closed this as completed Jun 10, 2020
@o-t-w
Copy link

o-t-w commented Aug 28, 2023

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

@sashafirsov
Copy link

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/[email protected]/demo/external-template.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review Progress: stalled Review type: CG early review An early review of general direction from a Community Group Topic: components Topic: HTML Topic: modules
Projects
None yet
Development

No branches or pull requests