The slides included earlier in the thread are up-to-date. The link to the
GitHub is for the Observable type that the syntax is expected to emit and
consume.

J

Dictated using voice recognition. Please forgive the typos.

On Jun 12, 2014, at 10:02 AM, John Barton <johnjbarton at google.com> wrote:

I urge TC39 to assess the cost/benefit of <module> carefully. It brings in
a lot of issues orthogonal to JS. <script> is already a mess and HTML
Imports are barely a thing. Web developers need a solution to the bundling
problem for ES modules with much, much higher priority than <module>.


On Thu, Jun 12, 2014 at 2:22 AM, David Bruant <bruant.d at gmail.com> wrote:

> Le 11/06/2014 18:21, Ben Newman a écrit :
>
>  ## 7.1 <script type=module> status update (from DH)
>>
>> DH: Would really rather have <module>import { foo } from "bar";
>> ...</module>, which is like <script> but async, strict mode, has its own
>> top-level scope, and can import declaratively (using ES6 module import
>> syntax) from other (named) modules.
>>
> Just to be sure I understand, with <module> (or <script type="module">),
> the module has to be named? So <module> never really makes sense on its own
> and should always have a "name" attribute?
>
>
>  DH: <module name="qux"> creates race conditions with HTML imports (part
>> of WebComponents).
>>
>> YK: People who saw named HTML module tags though you should mix html
>> imports w named module imports
>> YK: When you have packaging solution (SPDY, etc), you no longer need
>> named modules
>>
> +1
>
>
>  MM: <script type="module"> would inherit the special termination rules of
>> </script>, whereas old browsers might not handle <module> the same way,
>> since that tag name doesn't mean anything special in old browsers
>>
>> AR: <script type="module"> means the browser won't even try to parse it
>> as JS, which is what we want [so that we can execute the script contents as
>> a module, via some sort of polyfill]
>>
>> DH: <script type="worker"> might also need to have the <script
>> type="module"> semantics, and type= attribute syntax makes it hard to mix
>> and match those attributes; maybe <script worker module> would be better?
>> (i.e. the type attribute values become optional value-less attribute names)
>>
>> DH: The difference between <script type="module"> and <module> is that as
>> long as there's ... you always have the option of writing
>> <script>System.import("main.js")</script>
>> TODO: Get DH to clarify this point when we edit the notes.
>>
> cc'ing Dave Herman for this part.
>
>
>  AR: [note taker (BN) may be misinterpreting] The JS API remains important
>> even when we have HTML sugar.
>>
> Was this part edited after the "misinterpretation" or is it the original
> note?
>
> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140612/d34a7688/attachment.html>

The slides included earlier in the thread are up-to-date. The link to the
GitHub is for the Observable type that the syntax is expected to emit and
consume.