Changing the System loader vs creating a new loader

[guybedford]

I'd be interested to know whether it would be encouraged to override the System loader:

  System.resolve = function() {}

this is what is shown in Yehuda Katz's essay.

Or whether it should be assumed that the System global will always be the predictable browser specification, and any new loader should be a separate global.

Particularly with regard to the new <module> tag as well.

For example, if users wanted to load AMD modules, would they be expected to change the System loader to work with AMD modules, or create a new loader?

[jorendorff]

Maybe @dherman and @samth can weigh in on this.

From my perspective, hacking the System loader is like hacking sys.path in Python. It is totally normal and expected for the first few lines of JS that run in a Web page to configure the System loader. It would be weird for library code or even ordinary application code to modify System loader hooks, but that is possible too, and perhaps useful in some cases.

[samth]

I agree with @jorendorff. If you want a different loader, modifying System is probably the easiest way to go. We've tried to make it so that you don't have to create new Loaders unless you're really trying to create a new separate execution environment.

[guybedford]

Sure, this makes a lot of sense. Modify the System loader within conventions.

I'm just imagining a scenario where I load a third party script on a page (say a Facebook widget for example).

It will want to do its own module loading. If the System loader can be reliably trusted to load from a URL then that is great. Otherwise I suppose such code can always just internally create its own loader with its own baseUrl and global object - since the actual overhead of creating a loader isn't that bad anyway.

Education will happen naturally around this I think - since introductions will all be based around the System loader and frameworks / scenarios like the above that need custom loaders would develop their own.

[guybedford]

Just thinking about this a little more...

The only way to ensure full trust that I can use the System loader on a page (say in an embedded third party script), would be if the only configurable part of the System loader was the baseURL, and everything else would be guaranteed to remain predictable.

Perhaps it is worth considering disabling overrides of the hooks for the System loader, and instead allowing this process for custom loaders only?

[neonstalwart]

@guybedford i would imagine that in the case you're describing (a 3rd-party widget) it would want/need it's own loader so that it was a completely separate execution environment. you wouldn't want your widget to be effected by (or cause any effect to) the page that hosts it. i think this is a great example of why there needed to be a way to create your own loader.

[jorendorff]

Exactly. If you need to run code you don't trust, you must at least use a separate Loader. (I don't expect things to be super easy even then, because secure sandboxing is hard!)

[guybedford]

Ok great, sounds sensible to me.