Mark S. Miller-2 wrote: > > On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak < > medikoo+mozilla....@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. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
