On Mon, Jan 16, 2012 at 10:33 AM, Mariusz Nowak <medikoo+mozilla....@medikoo.com> wrote: > 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.
This is provably false. You normally do not need hundreds of modules to build a site. But even then, I know of very big, webmail-class web apps, AOL Webmail in particular, that loaded all module individually in dev. This was with the old dojo module system, but similar idea to modular loading. I believe the Closure library works in a similar way. That worked fine, and given the debugging capabilities of browsers, works the best for development. The load cost on a developer's desktop is not a factor, particularly given the easier debugging it enables. Could it be faster? Yes, and in the dojo case, switching to async script tags via AMD made it faster. But building one big file and trying to debug that is not the answer. *But more importantly*, harmony modules also seem to be designed to allow a separate request for each module. So your dislike of that attribute will not go away with harmony modules. Harmony modules may not need the function wrapper around the code as AMD does, but the network request behavior will be similar to AMD. In both AMD and harmony modules, you can use build tools in dev if you like, perfectly fine. However, mandating build tools just to get started with modules is not an easily scalable answer. It is is favoring complexity outside an individual module to avoid a function wrapping inside a module (in today's world with AMD -- hopefully not required in harmony). Complexity via tool selection, installation and configuration. Usually a different configuration when in dev vs. deployment. It also means that developers have to make a choice, do extra work to share their modules on CDNs. > 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. I believe Axel overreached in that comment. However, AMD is looking really strong: multiple, thriving implementations that are coordinating on specs, support in base JS libraries, and use on real sites. There is not another option for browsers today that has that type of breadth and depth. "Use tooling to bundle up CommonJS modules" does not allow for dynamic loading, even of built resources. The "tooling+CommonJS" approach is incomplete. It does not get into some of the harder bits of web delivery. I am hoping for something better than AMD in the next ES, and hopefully AMD can better inform that effort -- be the one to run through the gauntlet and hit all the nasty bits. That was the point of the ECMAScript feedback section in the blog post. On that note, back to the main thrust of that feedback, mostly summarized as: the compile time leanings and new syntax in the harmony proposal have some disadvantages, and at least at the moment with my current understanding they outweigh the advantages, at least for me as an end user. Some things are just tweaks on the existing proposal though, like always using string IDs. James _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
