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
dandclark opened this issue Jan 16, 2019 · 6 comments
Open

HTML Modules #334

dandclark opened this issue Jan 16, 2019 · 6 comments

Comments

@dandclark
Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

@travisleithead travisleithead commented Jan 29, 2019

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

This comment has been minimized.

Copy link

@kenchris kenchris commented Jan 30, 2019

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

@kenchris kenchris closed this Jan 30, 2019
@kenchris kenchris reopened this Jan 30, 2019
@torgo torgo added this to the 2019-02-05-f2f milestone Feb 5, 2019
@torgo torgo added the extra time label Feb 5, 2019
@matthew-dean

This comment has been minimized.

Copy link

@matthew-dean matthew-dean commented May 10, 2019

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

This comment has been minimized.

Copy link

@kenchris kenchris commented Sep 10, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.