On Mon, Jan 16, 2012 at 10:33 AM, Mariusz Nowak
> 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.