detecting JS language mode for tools
bruant.d at gmail.com
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 gmail.com> 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";
> 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
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