Unapologetically AMD

I’ve been working with JavaScript AMD modules for the better part of a year now and they have completely revolutionized the way I write JavaScript. Requirejs 2.0 brought in some excellent changes and, most importantly, made the shim concept a first class configuration option to make non-compliant code more easily usable.

Unfortunately, AMD adoption seems to be relatively low and the bulk of what you get as AMD-compatible libraries are things written as regular, all-encompassing, terrified of dependencies JavaScript libraries with an AMD wrapper around them. Using tools like Backbone and Backbone.Marionette combined with requirejs almost feels like cheating when it comes to writing single-page JavaScript applications, but I’m always left with a bad taste in my mouth when I try to look for other tools. You can go far organizing an application structure that is eminently extensible and maintainable and then feel like an unwashed slob as you try and wedge some jQuery plugin into a Backbone view that requires some obscure DOM structuring.

Everything seems to want to act as a plugin to something else, which is to say have only one dependency. This mindset forces code down a rabbit hole of duplicated code, omitted features, or substandard implementations. AMD is one of these answers to dependency management and packaging. It’s not a full answer, and it has some quirks, but the benefit is vastly greater than the cost.

I’m done with fitting square pegs into round holes and am now experimenting with an ecosystem of no holds barred, fully AMD modules that are compatible/complementary to Backbone, but we’ll see.

I just know I’m now done with shimming the world.

Leave a Reply