Skip to Main Content
Official App
Free – Google Play
Get it
FreshBooks is Loved by American Small Business Owners
FreshBooks is Loved by Canadian Small Business Owners
FreshBooks is Loved by Small Business Owners in the UK
Dev Blog

Writing Clean Maintainable JavaScript

by coe on November 15/2010

JavaScript comes with a bit of historical baggage — it’s that thing that you don’t rely on, that thing advertisers use. Perhaps this is why design best practices have, in the worst case, been ignored in JavaScript and, in the best case, lagged behind other languages. I don’t think I’m putting forward anything revolutionary in this post, I just wanted to introduce some of the methodologies I employ to write elegant, maintainable, JavaScript code.

I recently built Schedgy, a lightweight calendaring application, for scheduling support shifts at FreshBooks. Schedgy allows our support scheduler to drag and drop employees onto the days of a month, indicating the shifts they will be working.

I am going to use Schedgy to frame the conversation.

1. Don’t Treat JavaScript Like a Second-Class Citizen

I approach a JavaScript problem like I approach any software design problem — I decompose the problem space into a logical domain model. I am in the habit of using John Resig’s Simple Inheritance Micro Framework. This provides the classical inheritance I crave, having come from Java-land in a past life. Using something like Mootools, or plain old prototypal inheritance works too — as long as you don’t sit down and hack your code into a single function.

For Schedgy, I built the following model:


The actual Calendar object — contains Day instances, and encapsulates the logic for flipping between months.


The days of the month. A calendar maintains a reference to many of these. A day maintains a list of many Users, representing people assigned to a support shift on a given day.


Represents an employee at FreshBooks — it has their email, their first name, their last name, and various other instance variables. There is one underlying user object for a given employee, which can be referenced by multiple days.

Day Requirements

How many people do we need on support on a given day? Do we need at least one developer? This object encapsulates this logic. DayRequirements objects are attached to days.

Here’s what the code ended up looking like:

2. Use MVC

When writing client-side JavaScript, a common mistake that developers make is tightly coupling the domain model and the view. I’m sure everyone has seen something like this:

This is fragile.

People accustomed to frameworks like Rails are familiar with using an MVC design pattern to avoid this on the server-side, similar methodologies should be applied on the client-side.

I have two hammers that I like to use for this:

1) For large, dynamically generated, chunks of HTML, I use JSON Template to abstract rendering away from my core models. In Schedgy I use JSON Template for dynamically generated elements, such as the HTML snippet for a user being assigned to a day.

Here’s an example:

2) I use jQuery’s $.data() method to attach references on UI elements back to the underlying domain models. Here’s an example of this in action, from Schedgy:

I find applying this approach helps create much cleaner code than, for instance, relying on attributes on a DOM Element to drive behaviour.

3. Unit Test

One complaint I’ve heard about unit testing JavaScript is how difficult it is to exercise view logic. If you follow my two tips above, and keep your view logic as separate from your domain model as possible, this complaint quickly becomes moot. Sure, pull in Selenium for testing your UI. But approach testing your models like you would in any other language.

I have two tools which I use on a regular basis:

1) QUnit is a great unit testing framework, and is tailored towards usage with jQuery. Use QUnit — it runs in any web-browser, and works awesome.

2) Those familiar with RSpec might find JSSpec interesting. Under the hood, it’s a bit hacky (relying on eval() and regex to drive its DSL), but, having said this, I love using it. It makes clean readable tests.

Here’s a good example of an JSSpec specification from Endtable, a Couch ORM I have been working on:

Schedgy is open-source if you want to check it out — it works nicely for our use-case, but keep in mind it was build during a FreshBooks HackOff and the code could certainly use some love.

Schedgy on Github

Let me know in the comments if you find this post useful. I wouldn’t mind writing a few more along the same line.