permalink

5

Writing Modular JavaScript With AMD, CommonJS And ES Harmony

When we say an application is modular, we generally mean it's composed of a set of highly decoupled, distinct pieces of functionality stored in modules. As you probably know, loose coupling facilitates easier maintainability of apps by removing dependencies where possible.

In this article, we're going to look at three formats for writing modular JavaScript: AMD, CommonJS and proposals for the next version of JavaScript, Harmony.

The read the rest of this article, click here.

5 Comments

  1. This article is really nice, a good compilation of information that was otherwise spread all over the place!

    I am curious if you know any solution that makes it easy to take AMD/CommonJS-based libraries and build them (such as with yui compressor or similar) in a manner that does not require a script loader?

    I maintain a library that I am converting to CommonJS and then using the r.js conversion tool to build AMD modules out of them for use in-browser. The problem is a large portion of my audience still aren't using script loaders, and I don't want to force them to take on the additional complexity. I would like to be able to provide them with an alternate file that has all of these modules under one global object (the old way).

    • Hi Kyle,

      I would recommend checking out the RequireJS optimizer (if you haven't already), which allows you to combine your various script modules into one (or more) files and then minify them using UglifyJS – it's actually part of r.js, so unsure if you've explored it. Using this, your users don't have to rely on a script loader and a lot of the process doesn't require significant manual effort to get setup. Check out the optimizer here: http://requirejs.org/docs/optimization.html.

      Are you looking to generalize the module namespaces into a more global one using the process you mentioned or are you just looking for a solution like the above?

      Cheers!
      Addy

  2. Hi,

    Thanks for the good article!

    I have a short question: is it possible to monkey patch a dependency somehow ?
    With Object Literal it is quite easy to override the default behavior of a method thru the prototype but with AMD the dependencies come as function arguments and I'm not sure whether it is still possible.

  3. Stellar article!
    I've been wanting to implement AMD (require.js specifically) on some of our larger apps, but running into a roadblock in that we currently address caching using auto-incrementing numbered js and css files.

    How would you recommend using AMD loaders when util1.js might be called util2.js upon the next update? Any clever ideas?

    Most of our built files can be optimized together, but there's a few that will need to be loaded per-page or lazily.

  4. Hello Addy,

    Thanks for your reply.

    It took me some time to find the final answer but you pointed me in the right direction. I was familiar with the RequireJS build process, but the trick was trying to find a way to build them into one file, under one global variable and not need to have my users understand anything about RequireJS or include it in their project. In order to offer my library in both formats.

    On this page: http://requirejs.org/docs/faq-optimization.html I found a reference to another project by James Burke called “Almond” : https://github.com/jrburke/almond which is a light-weight AMD API shim.

    By wrapping Almond into my build I can now develop and use my library as AMD modules while also allowing it to be optionally used without a script-loader, here is my build profile:
    https://github.com/hapticdata/toxiclibsjs/blob/master/utils/build_profiles/app.build.js

    Thanks again for your help! Keep up the great work.

    – Kyle

Leave a Reply

Required fields are marked *.