We share the concern Jonas expressed here as I've repeatedly mentioned on another threads.
On Nov 18, 2013, at 4:14 PM, Jonas Sicking <jo...@sicking.cc> wrote: > This has several downsides: > * Libraries can easily collide with each other by trying to insert > themselves into the global using the same property name. > * It means that the library is forced to hardcode the property name > that it's accessed through, rather allowing the page importing the > library to control this. > * It makes it harder for the library to expose multiple entry points > since it multiplies the problems above. > * It means that the library is more fragile since it doesn't know what > the global object that it runs in looks like. I.e. it can't depend on > the global object having or not having any particular properties. Or for that matter, prototypes of any builtin type such as Array. > * Internal functions that the library does not want to expose require > ugly anonymous-function tricks to create a hidden scope. IMO, this is the biggest problem. > Many platforms, including Node.js and ES6 introduces modules as a way > to address these problems. Indeed. > At the very least, I would like to see a way to write your > HTML-importable document as a module. So that it runs in a separate > global and that the caller can access exported symbols and grab the > ones that it wants. > > Though I would even be interested in having that be the default way of > accessing HTML imports. Yes! I support that. > I don't know exactly what the syntax would be. I could imagine something like > > In markup: > <link rel=import href="..." id="mylib"> > > Once imported, in script: > new $('mylib').import.MyCommentElement; > $('mylib').import.doStuff(12); > > or > > In markup: > <link rel=import href="..." id="mylib" import="MyCommentElement doStuff"> > > Once imported, in script: > new MyCommentElement; > doStuff(12); How about this? In the host document: <link ref=import href="foo.js" import="foo1 foo2"> <script> foo1.bar(); foo2(); </script> In foo.js: module foo1 { export function bar() {} } function foo2() {} On Nov 18, 2013, at 4:52 PM, Scott Miles <sjmi...@google.com> wrote: > The HTMLImports we've been working with so far is not primarily about JS, > it's about HTML. > There are already various ways to modularize JS, including requirejs, other > libs, and of course, ES6 modules. > Isolation of globals has definite use cases, but it also has costs, and is > more intervention than is required for first-party use cases. It's been > argued (convincingly, from my perspective) that isolation can be successfully > implemented via a separate opt-in mechanism. I understand your perspective but has anyone outside Google shared the same opinion? If so, could you give us pointers (URL to a post, etc..)? > I suggest that keeping HTMLImports as primitive as possible is a virtue on > almost all fronts. Running scripts in the host document while keeping the rest in a separate document isn't exactly simple IMO. If we kept a separate document & window object, then HTML imports behave more like an display:none iframe with automatic JS value binding. There is a huge advantage in matching iframe's behavior here. - R. Niwa