On Nov 21, 2013, at 10:41 AM, Hajime Morrita <morr...@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