Hao
Hao

Reputation: 6589

The state of Javascript module loading definition and module loaders

  1. Has there being a winner now between all the module loading definition? CommonJS, AMD, UMD, ES6. And what about module loaders out there, which one is the one we should use?
  2. Angular-cli on ng4 use SystemJS module loader, correct?

Upvotes: 0

Views: 294

Answers (1)

Max Koretskyi
Max Koretskyi

Reputation: 105439

If you're writing JavaScript I think you should definitely use ES6 modules (ESM). But since there are some limitations to the way ESM are implemented now in browsers - dynamic imports only supported in Chrome and named modules AFAIK are not even in the spec - you are forced to use module loaders. I'm using SystemJS for loading modules on demand. Unfortunately, it doesn't support ESM as well so they first need to be converted into any of the formats SystemJS supports. I choose CommonJS since it's the same format used on NodeJS and is more familiar to me. The conversion is conveniently done by TypeScript. Once there is a full support of ESM by browsers including the limitations I mentioned above most projects will be able to remove SystemJS dependency.

However, most front-ed applications now use module bundler Webpack. It transforms ESM modules into it's own module format (based on CommonJS) and hence you don't usually need a separate module loader. But since Webpack can't load modules it doesn't know about during build time, if you need dynamic 3rd party modules to be loaded during runtime, you still SystemJS. That's the case with the application I'm working on.

Upvotes: 1

Related Questions