6 June 2014 TC39 Meeting Notes

Jafar Husain jhusain at netflix.com
Thu Jun 12 07:06:32 PDT 2014

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


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140612/d34a7688/attachment.html>

More information about the es-discuss mailing list