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

I've made similar comments on various threads, so sorry if you've heard
this song before, but here are some basic comments:

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.

There are the principles that guide the design as it is now. You have lots
of interesting ideas there, but it feels like re-scoping the problem into a
declarative form of JS modules. I suggest that keeping HTMLImports as
primitive as possible is a virtue on almost all fronts.

Scott



On Mon, Nov 18, 2013 at 4:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> Hi All,
>
> Largely independently from the thread that Dimitri just started on the
> sync/async/-ish nature of HTML imports I have a problem with how
> script execution in the imported document works.
>
> Right now it's defined that any <script> elements in the imported
> document are run in the scope of the window of the document linking to
> the import. I.e. the global object of the document that links to the
> import is used as global object of the running script.
>
> This is exactly how <script> elements have always worked in HTML.
>
> However this is a pretty terrible way of importing libraries.
> Basically the protocol becomes "here is my global, do whatever
> modifications you want to it in order to install yourself".
>
> 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.
> * Internal functions that the library does not want to expose require
> ugly anonymous-function tricks to create a hidden scope.
>
> Many platforms, including Node.js and ES6 introduces modules as a way
> to address these problems.
>
> It seems to me that we are repeating the same mistake again with HTML
> imports.
>
> Note that this is *not* about security. It's simply about making a
> more robust platform for libraries. This seems like a bad idea given
> that HTML imports essentially are libraries.
>
> 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.
>
> 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);
>
> / Jonas
>
>