Modules feedback, proposal

Brendan Eich brendan at
Sun Apr 1 11:33:02 PDT 2012

I agree with you, auto-appending is too concrete and JS-only. We can't 
use auto-append as a fallback since it's ambiguous (foo and foo.js could 
exist) and we shouldn't prefer foo based on existence (we'd have to GET 
twice or otherwise probe for existence). We want names not to depend on 
whether the URI denotes an existing "file".

I don't agree with reinventing MIME, er, IANA Media, Types, though. The 
rules for content typing from HTML, specifically for <script src=>, 
should be adapted with as few changes as possible for out-of-line modules.


John J Barton wrote:
> On Sat, Mar 31, 2012 at 6:30 PM, David Herman <dherman at 
> <mailto:dherman at>> wrote:
>     >
>     > baseUrl + ID + ".js"
>     Yeah, I've thought about auto-appending ".js". I think you're
>     right that it opens up the possibility to be a little more abstract.
> Auto-appending makes the API less abstract:the arguments must be JS. 
> That in turn requires some new type-signaling string to opt out of JS 
> if you want to expand the loader to other kinds of dependents. 
> RequireJS uses a type-signaling prefix, 'text!notJS' and it has 
> different rules for things that end do or do not end in  '.js'. All of 
> this has value at the cost of complexity. I'd like to see the standard 
> file extension naming used by default.
> In the code:
>   System.load(["jquery.js", "underscore.js"], function ($, _) {})
> the string "jquery.js" and "underscore.js" are combined with path info 
> to create URLs. They identifies a resource, not a module; they should 
> hew to standard URL naming conventions. (The tokens $ and _ refer to 
> modules).
>  jjb
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list