« Return to Thread: Harmony modules feedback

Re: Harmony modules feedback

by Andrea Giammarchi-2 :: Rate this Message:

You are underlying my points too .. I am dealing on daily basis with highly dependent little modules and the build procedure takes care of packing everything together before deployment.

However, we are using a synchronous version of require, similar to the one used in node.js but that does not scale the day we would like to go asynchronous in order to lazy load on demand only needed code.

Specially on mobile HTML5 applications where the manifest file is included, the lazy loading is handled by the browser itself and the module will be almost instantly available once required later on if this was present in the manifest.

What is missing is simply a common way that scales across all requirements and I am sure you are using similar approach we do, stripping out requires, used only to order file inclusion before minification, using synchronous loading on demand during debug ... isn't it?

This is OK as long as your requirements won't change and, talking about google, they do lazy load on demand many parts of their namespace too in different applications 'cause a core of 1Mb does not simply scale over 3G connections ... if you don't need that functionality instantly then why creating such big package?

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?

About AMD, yuno is 1Kb minzipped and it resolve dependencies with parallels downloads so you might be interested in having a look.

On Mon, Jan 16, 2012 at 7:33 PM, Mariusz Nowak <medikoo%2Bmozilla.org@...> wrote:

Mark S. Miller-2 wrote:
>
> On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak <
> medikoo%2Bmozilla.org@...> wrote:
>
>> rauschma wrote:
>> >
>> > For incrementally migrating old code bases, it would make a lot of
>> sense
>> > to allow ES.next modules to import AMDs and vice versa.
>> >
>>
>> -1
>>
>> I'm not sure if I understood this correctly, but trying to support
>> backwards
>> what was never a standard is probably not good idea, and AMD didn't get
>> that
>> much momentum to make exception for that, for many it's still
>> controversial.
>
>
> While I agree that ES.next modules do not need to worry about AMD if it
> does not establish itself as a widely used de facto standard, I think we
> would all be better off if (the core subset of) AMD did become a wild
> success and ES.next felt the need to figure out how to manage the
> transition.
>
>

It's very subjective, for example I don't see any added value in AMD (also
subjective). I work with complex JavaScript (on client-side) applications,
and AMD is not for us. Let me explain:
The point is that there are two ways of thinking of modules, first is fine
grained, when you care about DRY then your modules are rather small, it
means that with AMD you would need to load hundreds of such modules
asynchronously it wouldn't work even in dev environment. You may say - ok
but you may pack it with [your favorite AMD packer] - then I ask, what's the
point of using AMD when I don't need to load my modules asynchronously ?

Other way of thinking is bigger picture: it's about modules that are larger
packs of small modules that are loaded on demand, and this is when AMD can
be useful, however again I don't see a point of using AMD just for that,
implementations of AMD that I looked at are heavy and over-bloated for such
simple need.

If you look at the most complex JS applications in a web Today (e.g. Google
+, Facebook) most of them are built exactly that way, fine grained modules
packed into larger packs that are loaded on demand. Facebook even has
they're own CommonJS style modules packer.

So @axel saying that AMD is already a browser standard and it's just Node.js
users that don't like it, is overstatement. I don't see a need for AMD in
ES5.next and I'll be happy to refactor my CommonJS style modules for Harmony
implementations when it will become a reality.

--
Mariusz Nowak
twitter: http://twitter.com/medikoo
github: https://github.com/medikoo

-----
Mariusz Nowak

https://github.com/medikoo
--

View this message in context: http://old.nabble.com/Harmony-modules-feedback-tp33125975p33149500.html

Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com.

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

« Return to Thread: Harmony modules feedback