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

On Tue, Nov 19, 2013 at 2:07 PM, Rick Waldron <waldron.rick@gmail.com>wrote:

>
>
>
> 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.
>

However ES6 modules do solve the list of downsides in Jonas' list. And ES6
modules create a scope so variables and functions declared in a module but
not exported do not pollute the global object as a side-effect of
declaration.

I think ES6 modules for HTML imports provide a good compromise between
current HTML import design (no modules just packaging) and total
iframe-like encapsulation (many practical and design issues).


>
> Rick
>
>
>