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

On Mon, Nov 18, 2013 at 8:26 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

> 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 <jonas@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() {}
>

I think you just invented the <module> element:
https://github.com/jorendorff/js-loaders/blob/master/rationale.md#examples

In fact, the list of concerns that Jonas listed is specifically addressed
by modules. So, my thinking is that why don't we leave imports alone and
let the modules solve these problems? HTML Imports is a higher-layer
vehicle -- it simply allows you to build a dependency tree out of HTML
files. In turn, HTML Imports use modules to apply proper scoping of
scripts. And everybody is happy :)

:DG<