Which Loader should be used?

[yuchi]

This experimental implementation uses SystemJS to resolve, load, execute and cache modules.

I personally don’t believe in the final product SystemJS should be used.
Let me state my rationale.

1. The source code is complex and IMHO brittle. It’s written is ES5 and simply concatenated in the final build.
2. Doesn’t expect a server to know about its existence and misses a lot of opportunities here.
3. Extension appending, sparse package.json files, and folders’ index support is somewhat hacked together and doesn’t feel strong enough. See issue Reaching perfect Node-style resolution without burden #5
4. Doesn‘t support combo loading.
5. Doesn‘t support pre-emptive modules’ dependencies knowledge (and parses files at runtime!).
6. Doesn’t support lazy loading natively (to get a Promise instead of a direct reference to the exports of a module) which could be very bad for performance tuning of apps (such as above-the-fold speedups). You probably do that with plugins.

On the other side there are some good parts that would be very sad to loose. In particular:

1. it works, and we don‘t need to maintain it;
2. it has a small yet strong ecosystem coming from jspm;
3. has a useful list of plugins to load different kind stuff.

---

Update — SystemJS does support pre-emptive module dependencies through a specific configuration: meta: { 'a-pkg': { deps: [] } }

---

Update 2017/01/09 — references to issues and to System.js plugins.

[jbalsas]

I think we need to define the set of requirements the loader should have so we can take a decision.

Historically the design goals of liferay-amd-loader for Liferay DXP (being able to use ES2015) distilled down the following features:

• Loading of named AMD modules
• Combo loading
• Mapping of paths and modules
• Conditional dependencies
• Configuration can be auto-generated

Later additions were:

• Support for anonymous AMD modules (without combo loading)
• Default URL parameters
• Loader can be namespaced
• Loader exposed methods can be hidden from the global context

What would you say is missing so we could use it? Do you see a way for us to implement what's missing in System.js, Require.js or other loaders to achieve this?

[yuchi]

Fast review.

Feature	System.js	Require.js
Loading of named AMD modules	yes	yes
Dynamic combo loading¹	no	no
Mapping of paths and modules	yes	yes
Conditional dependencies	no	no
Configuration can be auto-generated	yes	yes
Support for anonymous AMD modules	yes	yes
Default URL parameters	plugin	yes
Loader can be namespaced	no²	no
Hide AMD APIs from the global namespace	yes²	no

Notes

1. Combo loading can be done in Require.js as a list of concat-ed files and in System.js as a bundle. In Portal we need dynamic combo loading, which is a different story.
2. While in System.js you cannot namespace the Loader differently, the AMD APIs are actually not automatically injected in the global namespace.

[yuchi]

Also a great read for everyone on the topic is this discussion on System.js, systemjs/systemjs#1522.

[yuchi]

But the main reason to write a custom loader is #4.

[jbalsas]

Throwing FuseBox into the mix as well 😉

[julien]

I'll add pundle and assetgraph to the list