<div dir="ltr">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>.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 12, 2014 at 2:22 AM, David Bruant <span dir="ltr"><<a href="mailto:bruant.d@gmail.com" target="_blank">bruant.d@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 11/06/2014 18:21, Ben Newman a écrit :<div class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
## 7.1 <script type=module> status update (from DH)<br>
<br>
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.<br>

</blockquote></div>
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?<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
DH: <module name="qux"> creates race conditions with HTML imports (part of WebComponents).<br>
<br>
YK: People who saw named HTML module tags though you should mix html imports w named module imports<br>
YK: When you have packaging solution (SPDY, etc), you no longer need named modules<br>
</blockquote></div>
+1<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>

<br>
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]<br>
<br>
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)<br>

<br>
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.<u></u>js")</script><br>

TODO: Get DH to clarify this point when we edit the notes.<br>
</blockquote></div>
cc'ing Dave Herman for this part.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
AR: [note taker (BN) may be misinterpreting] The JS API remains important even when we have HTML sugar.<br>
</blockquote></div>
Was this part edited after the "misinterpretation" or is it the original note?<br>
<br>
David<br>
______________________________<u></u>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/<u></u>listinfo/es-discuss</a><br>
</blockquote></div><br></div>