So there’s lots of debate about the merits of pure JavaScript objects (using Prototypal Inheritance) vs constructor functions (classes). I was on the former bandwagon until recently when I realized there are a couple of really good reasons to use classes.

Assume the following: I have a situation where I use/reuse a single object in many different methods throughout my app. It gets modified and munged and poked and prodded until finally it dies a horrible death and disappears into the ether.

Simplified validation and object setup

Smaller, more readable codebase

Adds well-defined rules to an application

Disclaimer

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):

Re-usability

Modules can be used in multiple projects without modification

Adaptability

Can be updated or replaced without affecting the whole

Sustainability

It’s simpler and easier to develop discrete functionality

Stability

The more it’s used the better it’s tested (no wheel-inventing going on here)

Economicality

If the client (AKA, web browser) doesn’t need it, it doesn’t need to be loaded

Let’s get practical.

Re-usability

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.

Adaptability

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.

Sustainability

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.

Stability

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!

Economical…ity?

Lol. Anyway. There’s no use loading the Super Social Slider Form ME(tm) 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.

Minimize dependencies

Try not to use external libraries if you don’t have to. Don’t be afraid to write “pure” Javascript.

Hold on loosely

Modules should be loosely coupled. Don’t call a module or its methods directly, instead use observers.

Do only one thing

Include all functionality required for the module to work by itself within one module.

Keep these in mind when you’re starting an app and you’re good to go.

This is Jameson and his partner in crime. Notice that little popper toy. Notice the location. Yes it’s a parking lot. How did we arive at this situation? Well it’s simple:

They suckered me.

I thought it would be nice to get a board game for the adults to play. Where does one buy board games? At Toys ‘R’ Us of course. First mistake. I don’t know what I was thinking.

Second was when mama, ever so coy, batted her eyes and asked if he could play with the toy. Sure, I thought, what’s the harm. So then he’s pulling it everywhere through the store which is really cute.

Time to check out and the kid pitches a fit, of course. It was the perfect trifecta so yeah I totally caved and bought it. They got me. They got me good…but isn’t it so cute?!

I was just taking a look through my father in-law’s awesome record collection. Omg. Van Halen, Led Zeppelin, Fleetwood Mac… I could go on and on. So much incredible classic rock in one little egg crate.

Jameson took three little baby steps completely on his own today! His balance is great but he really doesn’t understand what he’s doing yet

Heather and I recently had our engagement pictures taken by the lovely ladies at The R2 Studio (heavy flash). They were incredible and made us feel like rock stars. Head over to the blog post and then check out the full set.

Update: Our photos also got featured on Hi-Fi weddings. Sweet!

Just started using JSCoverage for testing code coverage in Javascript. It’s super simple to implement—I even got it working with RequireJS (just had to make sure it was using relative URLs).

Um yeah, this is just awesome. Thanks Steve.