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

On Mon, Nov 18, 2013 at 7: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


This isn't how node modules or ES6 modules work. A module designed for use
with node can define properties on the `global` (ie. the object whose bound
identifier is the word "global") and this is the same global object making
the require(...) call. ES6 modules are evaluated in the same global scope
from which they are imported.

Rick