Modules: use of non-module code as a dependency

James Burke jrburke at
Sat Jun 30 16:16:14 PDT 2012

On Sat, Jun 30, 2012 at 11:19 AM, David Herman <dherman at> wrote:
> I'm curious why you didn't include what seems like the most straightforward answer to me: jQuery continues to work as it did before, and just like always, you include it via a script tag and subsequently access it as a global:
> <script src="jquery.js"></script>
> <script>
> ... $('#foo').blah().blah() ...
> </script>
> I'm wondering why you didn't include this option -- is it just because jQuery is a special case that creates globals, whereas you also want this to work for modules that don't create globals?

This is not just because it is jQuery, it is just for any baser
libraries a user may use that cannot update to new keyword syntax. One
of the options above was that jQuery could do a runtime check for a
Loader API like System.set(), but not do the new keywords.

One of the problems a module system should solve is automatic
dependency resolution. It should not require a developer to manually
map out the dependency tree and load *some* of them in another loader
system (plain script tags in this case) before using them. The harmony
module system will look bad, particularly since this is not an issue
with existing JS module systems.


More information about the es-discuss mailing list