Inline ES Modules

Andrea Giammarchi andrea.giammarchi at
Wed Jun 20 06:55:25 UTC 2018

Darien others replied about CSP but also `script-src data: unsafe-inline`
would work as well. There is no evaluation, or at least, nothing different
from loading static content there (OK, the dynamic import could be a
different story, yet if pre-processed I don't see it as useful, but surely
one day someone will prove me wrong ^_^;; ).

About IANA vs HTML, I think both should be supported, specially because
IANA states text/javascript is deprecated and most developers serve JS via
application/javascript, or JSON as  application/json (and there is no

WebKit / Safari handles both cases without issues, Chrome chokes on the
application/javascript but it's IMO a non sense to allow one but not the
other, so I've filed a bug:


On Wed, Jun 20, 2018 at 1:56 AM, Darien Valentine <valentinium at>

> Andrea: That is a really interesting approach. I would point out that
> using data URIs for js means the `data:` scheme has to be a permitted
> source for script-src. This allowance has roughly the same security
> implications as permitting `unsafe-eval`. I know most people aren’t using
> CSPs yet, but personally I’d be wary of a solution that makes it harder to
> adopt a strong CSP.
> A super dorky/tangential aside that probably doesn’t matter at all but ...
> I notice you used application/javascript for the media type. There’s a
> contradiction between the IANA media type registry and the HTML 5 spec with
> regard to the "correct" media type to use for JS. RFC 4329 says
> application/javascript is the only value that should be used, while HTML
> says text/javascript is the only value that should be used. I believe (not
> sure though) that this is because it’s the most backwards-compatible value.
> Given that the media types registry seems to be basically dead to web
> standards (if we follow the registry we can’t serve or post a bunch of
> media types acknowledged or defined by web standards at all, including
> image/webp, application/csp-report, etc) and the code has to run in a
> browser, I’d tend to think HTML is the better spec to follow ... though I
> guess when two specs contradict each other it’s hard to make an objective
> case for one being more authoritative. (I’d be curious if there’s a
> specific reason you know of to prefer to RFC definition though. When
> standards don’t align it breaks my tiny heart.)
> On Tue, Jun 19, 2018 at 4:09 PM Andrea Giammarchi <
> andrea.giammarchi at> wrote:
>> sorry, I meant:
>> JSON.stringify('data:text/javascript,' + moduleContentAfterTreeShaking);
>> On Tue, Jun 19, 2018 at 10:09 PM, Andrea Giammarchi <
>> andrea.giammarchi at> wrote:
>>> I think these are all nice to have features, but I also think we have
>>>> all the primitives we need to make it happen via pre-processing.
>>> I meant even synchronously, with a pre-processor that replace the
>>> imported module with
>>> 'data:text/javascript,' + JSON.stringify(moduleContentAfterTreeShaking);
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list