Harmony modules feedback

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Jan 17 09:41:33 PST 2012


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 <wes at page.ca> wrote:

> On 16 January 2012 14:20, Andrea Giammarchi <andrea.giammarchi at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120117/16d8e9da/attachment-0001.html>


More information about the es-discuss mailing list