Discussion of AMD vs. CommonJS Modules/2.0

gistfile1.md

Just want to chime in that I'm glad people are still interested in CommonJS Modules/2.0. We have a working implementation that hopefully will be of interest, and have factored out the generally applicable parts of our test suite. Also see the announcement thread on the CommonJS list.

That said, personally I've been a bit disappointed with the CommonJS community's lack of enthusiasm on Modules/2.0. We picked it up early in our project lifecycle, and ran with it full speed. At the time it seemed like a more standardized alternative to AMD.

However, over time it's become clear that AMD has not only won mindshare but also has a much more active group of maintainers and a better, more egalitarian standards process. Whereas, Modules/2.0 has only the perennially busy Wes Garland, leaving a self-hosted PDF spec in limbo for 10 months while we discover outstanding spec issues (the most important of which is an incompatibility between the transport format and plugins).

I'd hoped that Modules/2.0 would thrive, both from the inherent bias I have as a writer of the only feature-complete implementation, and from a vague feeling of support for anything associated with the CommonJS brand. But it seems clearer and clearer as time goes on that not only is AMD winning, but it has in fact won. And that's not a bad thing: as @jrburke is fond of saying, this module format stuff is just getting in the way of us writing actual software. It's just a bit bittersweet, is all.

Hey Domenic,

Thanks for alerting me to the plugin problem in CJSM/2.0. I was not aware that there were still some unresolved issues.

I really appreciate the work that you, Christoph, and Wes have done on CJSM/2.0. I'd like to see a convergence of AMD and CJS endeavors some day. Like everyone else, my time is limited so I haven't spent as much time as I'd like investigating CJSM/2.0.

Regards,

-- John

Domenic, I share your frustration but am not about to give up on CommonJS yet or call any one spec the winner.

It has been stated that CommonJS is the long-term solution while AMD can bridge the gap in the meantime. I believe this to be true. AMD is great if you use it for your front-end JS only (that is what it was designed for). As soon as you want to run your whole system on JS you run into limitations as it does not clearly separate concerns nor has a larger-picture philosophy.

I have built my entire toolchain on top of CommonJS and will soon be documenting many of the open source components needed to make that happen.

One key component that is already live is my loader (it supports AMD and generates CJS2 compliant programs):

https://github.com/pinf/loader-js

I recently gave a presentation about it:

http://vimeo.com/31089051

I also presented on CommonJS:

http://vimeo.com/31245393

Finally I have a presentation about some of my tools built on top of CommonJS that will leverage CommonJS to bring a new way of developing systems where tools are driven from the application/code:

http://vimeo.com/32354840

I hope to support NobleJS as an alternative loader for CJS2 programs generated by the PINF JS Loader. I just need to add package mappings support to NobleJS. I believe once we have a few interoperable implementations and package repository system up and running CommonJS will gain traction (especially if it is AMD compatible). I am working towards this with a CommonJS package integration and build service that also acts as a package repository for dynamic aync provisioning loaders such as the PINF JS Loader:

http://sourcemint.com/

I hope this information injects some optimism into your point of view about CommonJS and I am looking forward to one day soon when we have the CommonJS specs and compliance tests organized and well-received by the community. We are not far off.

Christoph