Modules: use of non-module code as a dependency

Azer Koçulu azer at
Sun Jul 8 16:20:06 PDT 2012

4) being able to bind variables/object paths to virtual package names.
this is what OneJS ( provides to its
users and it's being used for documenting and optimizing the code.

On Sat, Jun 30, 2012 at 4:16 PM, James Burke <jrburke at> wrote:
> 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.
> James
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list