Loader vs ES6 Classes

Juan Ignacio Dopazo jdopazo at yahoo-inc.com
Mon Aug 4 08:06:51 PDT 2014

> On Monday, August 4, 2014 11:48 AM, Axel Rauschmayer <axel at rauschma.de> wrote:

> > On Aug 4, 2014, at 16:33 , John Barton <johnjbarton at google.com> wrote:

> > As far as I can tell you are basically arguing that simple Loader hooks don't need object state. Of course that is true.

> No, I’m arguing that Juan’s code is basically “subclassing” a loader, overriding a method and calling that method. ES6 classes seem like a more elegant way of doing this. You’d get as much object state in the subclass as you want.

We are actually using state a lot for configuration. And there's ongoing discussion about how to do it. So far we've been extending the Loader instance with our own properties (e.g. loader.depCache = {}). The main reason is that we want our extensions to the loader to work both on new instances of the Loader class and on the System loader, which can't be subclassed.

Also, we want each of our extensions to the loader to be self-contained. The reason is that apps that have critical performance needs need to be able to pick the extensions they want instead of bundling everything in case they need them. Subclassing doesn't quite get along with this approach. We also expect performance critical applications to insert their loader extensions in the HTML page or to PUSH them using SPDY. This way, in browsers that have the Loader API, we avoid this situation:

Fetch HTML page -> Fetch Loader extensions -> Fetch the app's code

Some links to current discussion:

- Conditional loading configuration: https://github.com/systemjs/systemjs/issues/126
- Reconsidering extension process again: https://github.com/systemjs/systemjs/issues/158
- Package configuration: https://github.com/systemjs/systemjs/issues/141


More information about the es-discuss mailing list