Modules: use of non-module code as a dependency

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


4) being able to bind variables/object paths to virtual package names.
this is what OneJS (http://github.com/azer/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 gmail.com> wrote:
> On Sat, Jun 30, 2012 at 11:19 AM, David Herman <dherman at mozilla.com> 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 mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list