Re: [HTML Imports]: what scope to run in

On Nov 21, 2013, at 10:41 AM, Hajime Morrita <morrita@google.com> wrote:
> Seems like almost everyone agrees that we need better way to
> modularize JavaScript, and ES6 modules are one of the most promising
> way to go. And we also agree (I think) that we need a way to connect
> ES6 modules and the browser.
> 
> What we don't consent to is what is the best way to do it. One option
> is to introduce new primitive like jorendorff's <module> element.
> People are also seeing that HTML imports could be another option. So
> the conversation could be about which is better, or whether we need
> both or not.

This is a nice summary.

> * Given above, HTML imports introduces an indirection with <script
> src="...> and will be slower than directly loading .js files.

This is not the case when you're defining components/custom elements in the imported document
because you want both templates, styles, and inline scripts to define those custom elements in one HTML document.

> * HTML imports will work well with <module>-ish thing and it makes
> the spec small as it gets off-loaded module loading responsibility.
> This seems good modularization of the feature.

But authors have to opt-in to benefit from such modularization mechanisms.

> HTML Imports make sense only if you need HTML fragments and/or
> stylesheets, but people need modularization regardless they develop
> Web Components or plain JS pieces. I think the web standard should
> help both cases and <module> or something similar serves better for
> that purpose.

I'm fine with saying that link[rel=import] is a simple include and module element is the way to include modularized HTML and JS files. That, however, raises a question as to whether we really need two very similar mechanism to accomplish the same thing.

- R. Niwa

Received on Thursday, 21 November 2013 03:34:44 UTC