
Shimport: Use JavaScript modules in all browsers, including dynamic imports - octosphere
https://github.com/Rich-Harris/shimport
======
blauditore
The author highlights support of dynamic imports multiple times. But why; is
there something particularly interesting about it? Other module systems did
this ages ago, e.g. RequireJS, so it's not like that's the main reason to
adopt JS modules.

~~~
exogen
The interesting part is that it's officially part of the ECMAScript spec and
HTML standard, and this library is just polyfilling it temporarily until more
browsers implement it – so eventually you can use the exact same syntax and
function calls without this library.

Things like RequireJS have certainly served people perfectly well, but they're
just systems that folks came up with and implemented in userland rather than
any official standard – you will always need a library to use them.

~~~
TheAceOfHearts
A minor nitpick, but the dynamic import proposal [0] is actually in stage 3 of
the TC39 process [1].

Although you are correct that the WHATWG HTML spec requires implementing the
import() proposal if JavaScript is supported.

[0] [https://github.com/tc39/proposal-dynamic-
import](https://github.com/tc39/proposal-dynamic-import)

[1] [https://tc39.github.io/process-document/](https://tc39.github.io/process-
document/)

------
TAForObvReasons
> in all browsers

Does it work in IE9 (still relevant since it is mandated by certain
governments)? The GH README has no statement of browser support.

~~~
finaliteration
It looks like it expects Promises to be implemented (there’s a Promise.all
call in the minified unpkg version), so unless you add a Promises polyfill
then I’d say it isn’t compatible with IE9.

~~~
nailer
> so unless you add a Promises polyfill then I’d say it isn’t compatible with
> IE9.

I agree with your technical assessment, but I'd put it: just add a Promises
polyfill and it's compatible with IE9.

This is of course assuming someone is paying you large amounts of money to
make a website that works on IE in 2018 - the gulf is so huge these days
between the 4 major evergreens that's a bunch of extra work, but if you have a
customer with fat pockets, then be my guest.

Edit: you added something about governments - which governments require IE9?

~~~
MBCook
I can’t speak to 9 but I have to work on a site that requires Java applets
(yeah) and the only browser left is IE 11. So until that changes it gets
supported.

------
pknight
See also the recent alpha release of SystemJS
[https://guybedford.com/systemjs-2.0-alpha](https://guybedford.com/systemjs-2.0-alpha)

------
k__
Can you cache modules?

------
tobyhinloopen
> new Function('import("' \+ src + '")')();

oh god the horror. using EVAL AND not escaping the input. Can't you just check
presence of `require`?

~~~
exogen
Unfortunately no, because `import` is special syntax that just happens to look
like a function call. It's not actually a function/object/etc. in the global
scope. Here's what Google's guide to `import` says about it:

> Note: Although import() looks like a function call, it is specified as
> syntax that just happens to use parentheses (similar to super()). That means
> that import doesn't inherit from Function.prototype so you cannot call or
> apply it, and things like const importAlias = import don't work — heck,
> import is not even an object! This doesn't really matter in practice,
> though.

Using eval (or the Function form of it in this case) doesn't seem like a huge
issue here, because if you're accepting a user-supplied `src`, it doesn't have
to contain any malicious syntax escapes in the `src` string itself to do
whatever it wants...they could just supply a perfectly normal script URL of
their choosing that will be executed anyway.

