detecting JS language mode for tools

Brendan Eich brendan at
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 mailing list