5 June 2014 TC39 Meeting Notes

[Domenic Denicola]

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-bounces at mozilla.org> on behalf of John Barton <johnjbarton at 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 <bruant.d at gmail.com<mailto: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<mailto: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/b537a64e/attachment.html>