Harmony modules feedback

Mariusz Nowak medikoo+mozilla.org at medikoo.com
Mon Jan 16 10:33:22 PST 2012



Mark S. Miller-2 wrote:
> 
> On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak <
> medikoo+mozilla.org at medikoo.com> 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.



More information about the es-discuss mailing list