I like <module>, simply as a better <script>. Whether it's worth the cost is largely a matter of finding out what the cost is, from implementers. I don't recall reading any opinions from them on the matter.
Hixie has brought up some interesting points on the interaction of <module> and <script> in <https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868,> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868? which may have bearing. Ideally <module> does not use <script>'s insane parsing rules, but there is a lot of complex stuff there that I don't think I fully grasp. Also, David: <module>s are not named; you cannot import them. Check out https://github.com/dherman/web-modules/blob/master/module-tag/explainer.md ________________________________ From: es-discuss <es-discuss-boun...@mozilla.org> on behalf of John Barton <johnjbar...@google.com> Sent: Thursday, June 12, 2014 10:02 To: David Bruant Cc: Ben Newman; es-discuss Subject: Re: 5 June 2014 TC39 Meeting Notes 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 <bruan...@gmail.com<mailto:bruan...@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@mozilla.org<mailto:es-discuss@mozilla.org> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
