detecting JS language mode for tools

David Herman dherman at
Mon Jan 27 12:03:24 PST 2014

On Jan 27, 2014, at 10:58 AM, David Bruant <bruant.d at> wrote:

> Agreed. Note that I didn't suggest to stop writing inline scripts and proposed an alternative to script at module that can work today.
> Granted, it's somewhat hacky, but I think it can work during the period during which there'll be both ES6 and non-ES6 browsers to support.
> I was sloppy in my phrasing. What we don't need is the current inline script "execute right now and block everything else" semantics, specifically for modules which order of execution shouldn't block things.

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.

Moreover, the type="module" should not actually mean "execute right now and block everything else," but rather "executing asynchronously once all my module dependencies are loaded and linked."

Does that make more sense? I realize part of the issue here is there isn't a concrete plan or proposal that's been spelled out, it's just been informal discussions. That's on us, the modules champions, to put forward a proposal for web (i.e. non-Ecma) standardization ASAP. Yehuda's going to be in town for TC39 this week, so he and I will sit down and do an informal write-up so people can see the plan more clearly, while we work on a fuller proposal for standardization.


More information about the es-discuss mailing list