detecting JS language mode for tools
brendan at mozilla.com
Mon Jan 27 14:56:29 PST 2014
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.
More information about the es-discuss