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

I'd frame the problem in a slightly different way.

Seems like almost everyone agrees that we need better way to
modularize JavaScript, and ES6 modules are one of the most promising
way to go. And we also agree (I think) that we need a way to connect
ES6 modules and the browser.

What we don't consent to is what is the best way to do it. One option
is to introduce new primitive like jorendorff's <module> element.
People are also seeing that HTML imports could be another option. So
the conversation could be about which is better, or whether we need
both or not.

If you just want to namespace the script, HTML Imports might be overkill because

 * An import is HTML and HTML isn't JS developer friendly in some
cases. Think about editor integration for example. Application
developers will prefer .js rather than .html as the container of their
code.
 * Given above, HTML imports introduces an indirection with <script
src="...> and will be slower than directly loading .js files.
 * HTML imports will work well with <module>-ish thing and it makes
the spec small as it gets off-loaded module loading responsibility.
This seems good modularization of the feature.

HTML Imports make sense only if you need HTML fragments and/or
stylesheets, but people need modularization regardless they develop
Web Components or plain JS pieces. I think the web standard should
help both cases and <module> or something similar serves better for
that purpose.

Does this make sense?

--
morrita



On Thu, Nov 21, 2013 at 7:00 AM, Rick Waldron <waldron.rick@gmail.com> wrote:
>
>
>
> On Wed, Nov 20, 2013 at 12:38 PM, Brian Di Palma <offler@gmail.com> wrote:
>>
>> On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron <waldron.rick@gmail.com>
>> wrote:
>> >
>> >
>> >
>> > On Mon, Nov 18, 2013 at 11: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() {}
>> >
>> >
>> >
>> > Inline module syntax was removed and will not be included in the ES6
>> > module
>> > specification. Furthermore, the example you've illustrated here isn't
>> > entirely valid, but the valid parts are already covered within the scope
>> > of
>> > ES6 modules:
>> >
>> > // in some HTML...
>> > <script>
>> > import {foo1, foo2} from "foo";
>> >
>> > foo1();
>> > foo2();
>> > </script>
>> >
>> > // foo.js
>> > export function foo1() {}
>> > export function foo2() {}
>> >
>> >
>> > (note that foo2 isn't exported in your example, so would be undefined)
>> >
>> > Rick
>> >
>>
>> I thought if an identifier wasn't exported trying to import it would
>> result in fast failure (SyntaxError)?
>
>
> Yes, my statement above is incorrect.
>
> Rick
>
>
>



-- 
morrita

Received on Thursday, 21 November 2013 01:41:47 UTC