Systemjs: What does "standards-based module loader" mean?

[TheMcMurder]

Questions

• How does SystemJS relate to standards and web proposals now?
• Is SystemJS implementing specific proposals?
• Is SystemJS an alternative proposal to something specific?

I recognize that I'm probably asking a few complicated questions. The world of browser/JS standards development is complex and I'm not sure where to look to find information.

Context

I am preparing a presentation on SystemJS and I realized that I've probably misunderstood some of the goals of SystemJS for some time. I'd like to correct my misunderstanding to better help others understand the value proposition of SystemJS.

SystemJS 0.20 had this in the readme:

Built with the ES Module Loader project, which is based on principles and APIs from the WhatWG Loader specification, modules in HTML and NodeJS.

SystemJS 2.0+ has this:

SystemJS is a hookable, standards-based module loader...

I had previously described SystemJS as _"a polyfill for a proposed web specification"_. But I'm wondering if I misunderstood what it was (pre 2.0) and that has prevented me from fully understanding how it relates to web specs and standards now (2.0+).

I wasn't able to find much when searching on this I did find some helpful stuff that lead me to believe that SystemJS 2.0+ is maybe not a poly-fill for a specific proposal.

• WhatWG loader specification is out of date (and maybe abandoned)
• System.import was the "old" loader API and to prevent issues with native resolution SystemJS chose to continue using the "old" loader API and not polyfill System.loader.import https://github.com/webpack/webpack/issues/2163

I really enjoy using SystemJS and I appreciate all the hard work that goes into it.

[joeldenning]

How does SystemJS relate to standards and web proposals now?

SystemJS provides a polyfill-like experience for specs related to module loading. The reason that SystemJS can't be a true polyfill is because browsers don't let code manipulate their module registries, module resolution algorithm, etc. (or in the case of IE11, the browser doesn't even have a module registry).

Is SystemJS implementing specific proposals?

These are the ones I know of:

• https://github.com/WICG/import-maps
• https://github.com/guybedford/import-maps-extensions
• https://github.com/WICG/import-maps/issues/137
• https://github.com/WICG/import-maps/issues/199
• import.meta.url (I don't know the link to that spec)
• import.meta.resolve (I don't know if there's a spec for this)
• Module registry api (I don't think there's an active spec for this)

Is SystemJS an alternative proposal to something specific?

SystemJS isn't a proposal. I don't know of alternative proposals for the specs that SystemJS is implementing.

[dmail]

I give my understanding on SystemJS in the following message but I am just an outside viewer. I mean, I can be wrong so take it with precaution.

I use SystemJS to transform my source code into a code compatible with more execution environments. Here execution environments means browser without some key features like import maps. In the end, I uses babel or rollup to transform source code into code in the SystemJS format.

SystemJS is the only format I know that comes with import-maps, top level await, import.meta.url, dynamic import and live bindings. I suspect other tools are able to provide something similar (I have in mind webpack). But I could not find a dedicated documentation about these. SystemJS got an independant and documented GitHub repository.

To me SystemJS is a format like UMD, IIFE, AMD...The is two main differences with them though:

• The "boilerplate" is shared in window.System. And you need to load it first.
• You must use System.import to use code in SystemJS format.

<script src="https://unpkg.com/[email protected]/dist/s.js"></script>
<script type="text/javascript">
  window.System.import('./dist/index.js').then(namespace => {
    console.log(namespace)
  })
</script> 

Finally I see SystemJS as something giving me control of module loading process. In development I use SystemJS with custom fetch and instantiate hooks to adapt how module are loaded in some cases. I use bare SystemJS (no custom hooks) in production. I prefer to keep my dependency to SystemJS basic for production because someday browser will have all the important features. That day it will make sense (at least for me) to deliver code in esmodule format and keep SystemJS only in dev. I estimate this day will not come before, at least, 5 years.

[TheMcMurder]

Thanks @joeldenning. That's a great summary to help me better understand how to describe SystemJS.