What Are Modules and Why Use Them?

By on

This post has stuff about religion. My perspective has changed

Update: This was going to be part of a series, but SitePen beat me to the punch with this incredibly exhaustive article, AMD : The Definitive Source. The title is completely accurate.

When it comes to developing scalable web apps (or apps of any sort really) it’s best to keep your code modular. Cowboy code won’t fly when your sweet porn app is getting nailed by a quarter million users in the time it takes to make a sandwich. Right. So, just to be clear I’m not talking about a specific architecture or methodology, I’m talking about approaching your code in a way that works for sites with large codebases and high traffic. IMHO this approach works for and should be used by small apps too. Just sayin.

Why modular architecture

For the love of all that is good, lets get to the point. There are at least five reasons to write modular code (in no particular order):

Every time you load up some random third party Javascript library you’re using modular code (some libraries are more modular than others). You stick it in, call it, and it does what it’s supposed to do. If you want to use that same library in a different project you can. So the next time Pointy-Haired Boss comes asking for a freaking contact form you can give him hell about how it’s going to take you four weeks to get it done, copy and paste the module, and go back to playing Half Life.


When said Pointy-Haired Boss decides that he hates the old contact form because “it’s not flashy enough” and wants to replace it with “something more social” or “something that slides out from the side like that one site” you’re good. Gut the old module (probably a bad idea) or create a new one. Either way, the module’s scope is limited so it’s not going to break the rest of the app.


Here’s a rhetorical question. What would you rather work on: a contact form whose functionality is randomly spread across 823 lines of code interspersed with navigation stuff, slidy thingies, some AJAX shit, and a handful of random global functions, _or_ 42 lines of contact form specific code located in a single file called contact_form.js? [5. Thank you very much, smart-ass. Now go read that Cowboy code link in the intro.] Projects big and small can benefit from this type of structure.


The first time you re-use your super-slidy contact form in a different project you will realize it has about a thousand shortcomings. It needs to be easily skinned, “ohmigod it has to slide from the right!”, and whatnot. So you fix it, update all instances, fix bugs, test, reuse. A year later you’ve got a really solid, semi-slidy social contact thingy that 9 other people on GitHub also use. YAY !


Lol. Anyway. There’s no use loading the Super Social Slider Form ME on every page of your app. Better to include it only where it’s needed. In fact, why not wait to load it until it’s actually needed. Modular code lets you do this kind of thing. When you have the 489kb, 823 line multi-function cluster-fuck version, the client gets it all at once. Kittens die because of this kind of shit. Be nice to your end users by conserving bandwidth, memory, and load times.

Rules To Live By

I’ll save the practicalities of putting together a real module for another post but before I that, there are a few rules to live by.