Brendan Eich wrote:
OK, sorry I jumped in the middle of things missing some context. In
fact, I think what we've been planning on proposing is not too far --
I think -- from what you're talking about. The plan is *not* a module
attribute (that was a think-o on my part, and maybe some
misinformation that crept into this discussion earlier?) but
type="module". That way on old browsers it's ignored and you can add
shims to load it. Shims can be made future-proof via feature
detection, so type="module" can obtain new semantics.
The shims word suggests that old-browser-targeted script must
DOM-scrape the script type=module text and interpret it with Esprima
or similar. This may not perform well enough compared to an AOT
compiler, which is another option. Just weighing these.
And the other thing to weigh is <script module>, which could work two
ways with enough care. Module loader API detected and used if present,
else a named exports object used as fallback.
The performance would be better in pre-ES6 browsers than any scraping
system, probably better than any AOT-compiled system. The ES6+ browsers
would see API calls instead of declarative export and import forms,
which might be slower -- or could perform within epsilon of declarative
forms (fast engines these days).
We could take our time on this and do it via a CR-level HTML extension,
which seems to be agreeable whether the attribute is type= or module. We
wouldn't couple it to ES6 or its status, but we could implement and
developer-test in nightly/canary rapid-release browsers.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
