4 ms·

For those thinking about using this, it bears mentioning that there are a few caveats to script type=module that makes it difficult to use with a lot of modern

For those thinking about using this, it bears mentioning that there are a few caveats to script type=module that makes it difficult to use with a lot of modern workflows, namely: 1. No way to dynamically import a module (the article explains this). 2. All imports must be relative or absolute urls, so either ./foo.js or /foo.js or http://example.com/foo.js http://example.com/foo.js This means you can't npm install lodash and import the string "lodash". 3. All imports must include the file extension (.js). So even if you set up a server route for /lodash it would break as soon as one of lodash's imports didn't use .js (or it imports another package). This is assuming lodash is written with import/export; it's not so it wouldn't work at all. 4. Until http2 comes around, this is probably not something you want to ship to production (unless you have a small app with only have a handful of scripts being imported), so bundlers are here to stay for a while. It might be possible to work around 1, 2, and 3 using Service Workers, I wrote about this a while ago: https://matthewphillips.info/posts/loading-app-with-script-module https://matthewphillips.info/posts/loading-app-with-script-m...

silverwind 10y ago
> All imports must include the file extension (.js) Or, .mjs [1]. [1] https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md#determining-if-source-is-an-es-module https://github.com/nodejs/node-eps/blob/master/002-es6-modul...
- nacs 10y ago
  > .mjs [1]. I was worried this was short for "Microsoft JS", thanks for the link.
WorldMaker 10y ago
The article doesn't mention 2 and 3, but just as with 1 the module loader spec that is not yet implemented would also happen to help address 2 and 3 by providing plugin mechanisms to support name mappings like automatic file extensions and mapping canonical module names like 'lodash' to file paths.
- MatthewPhillips 10y ago
  Just to clarify, the mappings for names to paths isn't enough to load an NPM-based project. With NPM you can have multiple semver-incompatible packages. It's very common to happen, actually. For example, you might depend on "foo" and "bar". "foo" also depends on "bar", but it needs version 1 and you need version 2. In this case, setting paths for "bar" won't work, the paths are different for each parent. The loader spec provides a hook "resolve" that allows you to work around this, just wanted to point out that configuration alone wouldn't be enough. It's also worth noting that the Loader spec doesn't have a real urgency to it. What I mean is that likely browsers will implement script type=module first, give it some time to brew, and then pull in things from whatwg/loader over time. In the meantime we'll want solutions that do allow us to use script type=module and still have modern workflows we are used to.
  - WorldMaker 10y ago
    I would hope that the Loader spec gets a bit more urgency as developers bump into the limitations of script type=module.
toomanythings2 10y ago
Until http/2 comes around? I've been using it for a couple of months on all our client sites and the standard was finalized last year. It's now available in all current, major browsers.
- hyperknot 10y ago
  Please have a look at the data before writing such statement. In the latest CloudFlare article [1] about it (Feb 2016), they concluded that only 52.93% of their users are connecting over HTTP/2. [1] https://blog.cloudflare.com/cloudflares-impact-on-the-http-2-universe/ https://blog.cloudflare.com/cloudflares-impact-on-the-http-2...
  - exclusiv 10y ago
    Nginx and other servers handle both automatically no?
    - hyperknot 10y ago
      Yes, but the problem is on the client (browser) side.
      - toomanythings2 10y ago
        I am not aware of any current major browser that does not support http/2. http://caniuse.com/#search=http%2F2 http://caniuse.com/#search=http%2F2
  - toomanythings2 10y ago
    Which statement? All major browsers can work with it. Apache and nginx, at least can also work with it (encompassing 85% of all internet servers). That users aren't connecting to http/2 web sites is no indicator that http/2 is not available.
    - hyperknot 10y ago

silverwind 10y ago

> All imports must include the file extension (.js) Or, .mjs [1]. [1] https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md#determining-if-source-is-an-es-module https://github.com/nodejs/node-eps/blob/master/002-es6-modul...

nacs 10y ago
> .mjs [1]. I was worried this was short for "Microsoft JS", thanks for the link.

WorldMaker 10y ago

The article doesn't mention 2 and 3, but just as with 1 the module loader spec that is not yet implemented would also happen to help address 2 and 3 by providing plugin mechanisms to support name mappings like automatic file extensions and mapping canonical module names like 'lodash' to file paths.

MatthewPhillips 10y ago
Just to clarify, the mappings for names to paths isn't enough to load an NPM-based project. With NPM you can have multiple semver-incompatible packages. It's very common to happen, actually. For example, you might depend on "foo" and "bar". "foo" also depends on "bar", but it needs version 1 and you need version 2. In this case, setting paths for "bar" won't work, the paths are different for each parent. The loader spec provides a hook "resolve" that allows you to work around this, just wanted to point out that configuration alone wouldn't be enough. It's also worth noting that the Loader spec doesn't have a real urgency to it. What I mean is that likely browsers will implement script type=module first, give it some time to brew, and then pull in things from whatwg/loader over time. In the meantime we'll want solutions that do allow us to use script type=module and still have modern workflows we are used to.
- WorldMaker 10y ago
  I would hope that the Loader spec gets a bit more urgency as developers bump into the limitations of script type=module.

toomanythings2 10y ago

Until http/2 comes around? I've been using it for a couple of months on all our client sites and the standard was finalized last year. It's now available in all current, major browsers.

hyperknot 10y ago
Please have a look at the data before writing such statement. In the latest CloudFlare article [1] about it (Feb 2016), they concluded that only 52.93% of their users are connecting over HTTP/2. [1] https://blog.cloudflare.com/cloudflares-impact-on-the-http-2-universe/ https://blog.cloudflare.com/cloudflares-impact-on-the-http-2...
- exclusiv 10y ago
  Nginx and other servers handle both automatically no?
  - hyperknot 10y ago
    Yes, but the problem is on the client (browser) side.
    - toomanythings2 10y ago
      I am not aware of any current major browser that does not support http/2. http://caniuse.com/#search=http%2F2 http://caniuse.com/#search=http%2F2
- toomanythings2 10y ago
  Which statement? All major browsers can work with it. Apache and nginx, at least can also work with it (encompassing 85% of all internet servers). That users aren't connecting to http/2 web sites is no indicator that http/2 is not available.
  - hyperknot 10y ago