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

On Wed, Nov 20, 2013 at 7:34 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

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

And in this model, the 'inline script' can use <module>, meaning that the
JS is modular and relies on modular JS. In this way the two specification
work together.

Earlier I suggested a way to combine these specifications from the other
direction, inventing a small extension to ES module-loader,
System.component(), where JS drives the load of an HTML import.


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

As I argued for modularity support previously, I also think there is a
strong case for non-modular forms as well: early adoption, test cases,
simple pages, purely declarative markup sites, future innovations.
 Enforcing modularization is likely, based on history, to lead to fewer
uses even much less that the amount of opt-in to a less rigid solution.
Just consider JavaScript vs every other solution for Web scripting, or HTML
vs XML.


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

The <module> element remains a rumor to my knowledge and this rumor has it
as a JS only feature. The rest of the module specification is far along,
but again only JS. The story for HTML is well represented...by the HTML
Import system.

The strength of the HTML Import story is declarative include of a complete
HTML sub-document, something we have never enjoyed as a common technology.
Its weakness in my mind is lack of advanced JS features like modules and
dynamic loading; these I see as great additions to be made by the JS
leaders.

I don't see two similar mechanisms for the same goal, but two cooperating
specifications with different strengths that combine nicely. At least on
paper, we need more empirical work with the combination to be sure.

HTH,
jjb