I can have lay load too with yuno ... nobody prevents you to do this

function Whatever(){}
Whatever.prototype.loadModule = function (callback) {
  yuno.use("requiredModule", callback);
};

// it could also be directly ...
Whatever.prototype.load = yuno.use;
// in order to be able to load anything needed later
// this won't be compatible with the smart builder though

Above code is already compatible with yuno for browsers ... I keep saying
that both CommonJS require and AMD define do not scale well with all
scenarios:

   1. smart build with possibility to create single package "all included"
   without code size overhead
   2. interoperability between formats
   3. backward compatibility with older script that do not export anything

yuno can be shimmed for node.js without effort and be used as AMD loader
with few changes ... the missing part I am working on is the smart builder
but I believe I'll do this in two steps ... still in progress, that's why
I'd like to have feedbacks now

br

On Tue, Jan 17, 2012 at 6:28 PM, Wes Garland <w...@page.ca> wrote:

> On 16 January 2012 14:20, Andrea Giammarchi 
> <andrea.giammar...@gmail.com>wrote:
>
>> var module = require("module");
>>
>> is totally fine but
>>
>> require("module", function (module) {
>>   // is totally fine too
>> });
>>
>> latter could be synchronous in node.js and asynchronous in the web, who
>> cares, as long as it scales for all scenarios ... don't you agree?
>>
>
> One fundamental difference between how AMD modules and CommonJS modules
> (presumably Node) load is that CommonJS modules have lazy initialization,
> whereas AMD modules have eager initialization.
>
> This is probably where some of the Node<>AMD "impedance mismatch" is
> coming from -- in CommonJS with Modules/1.0 on the server side, developers
> expect to be able to perform certain types of initialization when the
> module is loaded, and they do not expect to need to pre-declare their
> modules.
>
> It will be interesting to see how the addition of ES.Next modules plays
> out with the server-side JS communities.
>
> Wes
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to