detecting JS language mode for tools

David Bruant bruant.d at
Mon Jan 27 10:58:43 PST 2014

Le 27/01/2014 19:41, David Herman a écrit :
> On Jan 27, 2014, at 2:07 AM, David Bruant <bruant.d at> wrote:
>> Indeed. I'm wondering why we need inline <script> for modules.
> Because people write inline scripts all the time. It's unacceptably inconvenient not to be able to bootstrap your app with inline code. It also allows you to control for when the scripts resource is there, in particular to be sure that necessary bootstrapping/kernel code has loaded before you need to do some wiring up of your app.
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.

> But it's not even worth overthinking. It's so obviously, obscenely anti-usable not to be able to write
>      <script module>
>      import $ from "jquery";
>      import go from "myapp";
>      $(go);
>      </script>
> inline that I'm surprised this is even a discussion.
If the snippet is only targetting ES6 browser, it can work without the 
module attribute (I think?). This snippet doesn't work on non-ES6 
browsers, though.

I feel two different problems are being discussed in this thread? One 
about inline modules, one about compatibility, (both a bit away from the 
original topic ;-)). I was on the compatibility track.


More information about the es-discuss mailing list