Tobias Cohen

Hi, I'm Tobias, and I'm a web developer in Melbourne, Australia, specializing in Ruby on Rails and Coffeescript

How We’re Using Modules to Organize Our Front-End Code

19 Nov 2014

Ever wondered how a large site like Tuts+ keeps its CSS, HTML and JavaScript in order over continued development and iteration? I’m going to show you the process we’ve implemented to keep it all tidy and maintainable.

Problems with CSS

The first step in this process was finding a way to build the large amount of CSS we need that won’t inevitably end in chaos.

Traditionally with CSS, you build up styles as you need them, and strive to make your selectors broadly applicable so that they can be reused throughout the site. For example, here’s some simple CSS rules that would not feel out of place in most stylesheets:

h1 { font-size: 22px; }
.subtitle { font-size: 18px; }

If you need to override these selectors in a specific part of a page, you might use nested rules to construct selectors that target more specific elements:

.site-header h1 { font-size: 40px; }
.site-header .subtitle { font-size: 28px; }
.site-header a.navigation { color: #136FD2 }

This approach feels intuitively correct, however it can have some significant problems once you get to a site that has more than a few pages, and which more than one developer is working on.

What happens when we change the styling of h1 or .subtitle at a global level? font-size is already being overridden by a more specific style, but if we add a font-weight or line-height it won’t be. Any changes made to the global styles can ripple out and affect more specific styles in ways that aren’t predictable without an intimate knowledge of all styles on the site.

The more styles built this way, the more pronounced the “side effects” of interacting CSS styles will be, requiring tiresome trial and error to put right, and ultimately resulting in a loss of productivity and more bugs creeping through to production.

Read the rest of the article on