5 ms·

If you don't find JavaScript modules confusing, you should. I work on a module loader [1] and I find it quite confusing. To clarify we have 3 things: 1. import

If you don't find JavaScript modules confusing, you should. I work on a module loader [1] and I find it quite confusing. To clarify we have 3 things: 1. import and export syntax, this is defined in ES2015. It's just syntax, it doesn't explain how modules should be loaded. 2. The Loader spec (http://whatwg.github.io/loader/ http://whatwg.github.io/loader/) which defines a full loader including hooks to do just about anything you can possibly need. This allows you to do really crazy things like define modules dynamically and import then dynamically (which the static import/export syntax doesn't allow). We use this extensively in StealJS (or at least an older version of it) and it's pretty powerful. 3. import type=module is what this article is referring to. It defines a tag that allows you to import modules in the browser. You can't use a regular script tag, modules are different; they are strict mode by default for example. If you read the GitHub issue there was some discussion of whether import type=module should use the Loader spec. It probably should. But the Loader spec isn't done so... reading the spec and seeing things like the module map [2] it sounds like import type=script defines a miniature sized loader. I don't blame them for doing this, Loader has taken too long and people are clamoring for something. The Loader spec has a weird history; it was close to being done in ES2015 but when it was ejected it sit for a long time without much work. Then around last summer it was heavily worked on and got pretty far. But now as it sits, no commits like the last 2 and a half months [3] At this point I wouldn't be surprised to see Loader go away. It's probably too controversially and too big to ever get done. I imagine the web will just have the import type=module loader and Node will do it's own this. This is going to make writing portable JavaScript as annoying going forward as it's always been. [1] http://stealjs.com/ http://stealjs.com/ [2] https://html.spec.whatwg.org/multipage/webappapis.html#module-map https://html.spec.whatwg.org/multipage/webappapis.html#modul... [3] https://github.com/whatwg/loader/commits https://github.com/whatwg/loader/commits

CraigJPerry 10y ago
>> This allows you to do really crazy things like define modules dynamically In python there's a library called "sh" and it has a novelty interface: from sh import ls, pwd, my_unique_command print ls('/dir') ... I wondered (not enough to check right enough) if something similar could be done in JS. Although due to the async nature of such a call, it might not end up looking so familiar with JS in practice i guess.
- redka 10y ago
  https://github.com/shelljs/shelljs https://github.com/shelljs/shelljs Edit: \/ ahh, yes you're right!
  - foota 10y ago
    I think if I'm grokking correctly that you can import "anything" from sh, without it having to be explicitly in the package.
spankalee 10y ago
One detail that's often lost in the discussion (that you might have been hinting at) is that without a loader modules can only be referred to by URL. Node-style name resolution won't work at all. This means that modules will either still have to be compiled with something like browserify that resolves modules names into URLs ahead of time (a solution I don't particularly like), or modules will just have to use URLs to import other modules, leading to a convention of assuming that modules are all siblings so that you import like this: import * as jquery from '../jquery/jquery.js'; Despite the extra verbosity, I prefer this since it requires that modules are flat and de-duplicated and doesn't require any resolution step at all.
- MatthewPhillips 10y ago
  Modules are not flat in reality though, any non-trivial sized app likely has multiple versions of the same module being used. I don't see any reason to think that's going to change in the future, extreme modularity is the norm in JavaScript these days.
  - josteink 10y ago
    It may be the norm right now (since npm came around), but that's no reason to excuse it for what it is: a mess. A mess we should be able to do without. If we can have an official module-implementation which somehow forces developers to get a grip on their dependencies (which is the exact opposite of what "modern" js developers are doing), that can only be a good thing. The cowboy days must surely soon be over?
    - jessaustin 10y ago
      Every language and platform ever has had serious problems with multiple library versions. Anyone who has used an OS without a package manager knows this. I won't claim that npm doesn't also have problems, but at least its problems are different. Humanity can survive the existence of more than one paradigm for dealing with versioned libraries.
  - spankalee 10y ago

CraigJPerry 10y ago

>> This allows you to do really crazy things like define modules dynamically In python there's a library called "sh" and it has a novelty interface: from sh import ls, pwd, my_unique_command print ls('/dir') ... I wondered (not enough to check right enough) if something similar could be done in JS. Although due to the async nature of such a call, it might not end up looking so familiar with JS in practice i guess.

redka 10y ago
https://github.com/shelljs/shelljs https://github.com/shelljs/shelljs Edit: \/ ahh, yes you're right!
- foota 10y ago
  I think if I'm grokking correctly that you can import "anything" from sh, without it having to be explicitly in the package.

spankalee 10y ago

One detail that's often lost in the discussion (that you might have been hinting at) is that without a loader modules can only be referred to by URL. Node-style name resolution won't work at all. This means that modules will either still have to be compiled with something like browserify that resolves modules names into URLs ahead of time (a solution I don't particularly like), or modules will just have to use URLs to import other modules, leading to a convention of assuming that modules are all siblings so that you import like this: import * as jquery from '../jquery/jquery.js'; Despite the extra verbosity, I prefer this since it requires that modules are flat and de-duplicated and doesn't require any resolution step at all.

MatthewPhillips 10y ago
Modules are not flat in reality though, any non-trivial sized app likely has multiple versions of the same module being used. I don't see any reason to think that's going to change in the future, extreme modularity is the norm in JavaScript these days.
- josteink 10y ago
  It may be the norm right now (since npm came around), but that's no reason to excuse it for what it is: a mess. A mess we should be able to do without. If we can have an official module-implementation which somehow forces developers to get a grip on their dependencies (which is the exact opposite of what "modern" js developers are doing), that can only be a good thing. The cowboy days must surely soon be over?
  - jessaustin 10y ago
    Every language and platform ever has had serious problems with multiple library versions. Anyone who has used an OS without a package manager knows this. I won't claim that npm doesn't also have problems, but at least its problems are different. Humanity can survive the existence of more than one paradigm for dealing with versioned libraries.
- spankalee 10y ago