This content is over 12 years old. It may be obsolete and may not reflect the current opinion of the author.

I recently did some research on well-known Javascript module formats. Not sure why I missed this topic back in 2009, however some archeology revealed an conflicting reality:

• The most accepted package format, for Javascript in general, is the CommonJS format.
• However, the format is unfriendly to browser context, and it’s impossible to implement the loader 100% correctly.
• In the browser, people ended up using AMD format instead. Also, AMD try to incorporate CommonJS format by introducing special dependency names; see the 3rd and 4th paragraph of the spec.

For years, a lot of discussion on the difference of the formats surrounds the sync v.s. async nature of the format. jrblake, the author of the AMD spec and require.js, have already explicitly explain his argument on why he disagreed with the trade-offs made in the CommonJS module format.

However, I still ended up drawing the conclusion of my research — as of 2013, CommonJS modules is more welcomed to the developers than AMD modules. But why? In my humble opinion, of all the differences in design between CommonJS module and AMD module, this one stands out and made the difference: CommonJS module spec requires one scope per module. This in turn gives CommonJS modules the following behavior:

• Every module get a private scope, for free — the only things expose to others are the ones you explicitly expose in the exports object.
• In return, module scripts don’t get to access the globe object of the main context — e.g. the window object in browsers. This has significant implication — module scripts can never take global APIs for granted — one would have always explicitly require() for it. On the other hand, one could never mess up with the dependency system by attaching fake fake APIs on the global object — everyone has to be honest to the dependency tree, and the loader.
• Without the global object, native APIs available to the module would also need to be require()‘d. This in turn provided an uniform experience for the developers, which is extremely helpful to new Javascript runtime/platforms, both on inventing one and on learning one. With that, it is not surprising almost every “new kid in town” adopts CommonJS modules, e.g. NodeJS, PhantomJS, and Mozilla Add-on SDK.
• Limiting one file per module is pretty much an outcome of the scope design. It will be really hard to define scope syntax, to house multiple scopes within one file, and it will be even harder to implement.
• Same applies to sync dependency loading. If modules are loaded in their own scope, they could surely block the execution of requestee.
• Lastly, and sadly, one of the drawbacks of the one scope per module design: you can never ever simulate private scope in the browser reasonably. One could surely wrap CommonJS module into a function scope, or simulate sync loading with sync xhr and eval() (Yabble), but one would never stop script within from referencing variables on the outer scope s (except running your own Javascript runtime on top of the native Javascript runtime, I presume).

What does all that means

For someone who write Javascript for the browsers most of the time (we all are I think), I hate to be the proponent of something that doesn’t work in the browser context. What’s good come out of CommonJS module spec is all begin with the decision to ditch the browser. Alternatively, the legacy limitation of the browser is just too heavy for AMD module format to carry — thus, the AMD format never propagates, beyond browser, so does the promise to Javascript modules debate to the developers — you should be able to write your code once and use it everywhere.

What is broken, for modern day needs, is the browser context, not AMD, which tried really hard to address it. What AMD proofed is that we need new language feature, or browser APIs, to cope what we are facing. Hopefully, the new ECMAScript Harmony module is being worked on in Gecko and will be landed soon. How Harmony module could deliver the promise is not the scope of this article; it would be a further pending research topic for me.

An unified Javascript ecosystem awaits

Javascript, 18 years after invention, a fundamental cornerstone is still missing for building a library repository, like what PEAR for PHP, CPAN for Perl, or RubyGems for Ruby. The momentum is there already, and it had been there, for a long time. npm could be considered the most promising one, however, again, the lack of a common module format limits the uses of the modules on the site.

It also limits people writing heavy client-side web applications — people is currently prevented to split their apps into modules agnostically of any frameworks. This is worse than PHP, in which the frameworks have already start working together on common standards, i.e. PSRs.

We are still eagerly waiting another universal Javascript module format, to ignite everything and to start realize all the possibilities. I remain optimistic on this issue given the wide acceptance of the language itself had attracted lots of talents. But, first step toward the solution at full speed is to admit there is one.