Why Our Stylesheets Are Compiled Now: Sass on Team Projects

There is a moment in every long-lived CSS codebase, usually around the third team member and the thousandth line, when it becomes an archaeology site. The brand blue exists in four slightly different values, each with partisans. Overrides stack on overrides until nobody knows which rule is doing the work. Deletion becomes an act of faith, so nothing gets deleted, so the file grows, so the problem compounds.

We have dug through enough of these sites, our own included. So when the preprocessor movement matured this past year, we ran the experiment properly. A year of Sass on production builds, team-wide. The verdict is in our workflow now, which is the strongest form a verdict takes. This post is the reasoning for teams weighing the same move.

What a preprocessor actually is

The mechanics, for the unfamiliar. Sass, and its sibling LESS, more on the choice below, is a language that compiles to CSS. You write in the enhanced syntax. A build step produces the ordinary stylesheets browsers consume. Nothing about your site’s delivery changes.

What the enhanced syntax adds is exactly the toolkit CSS’s designers left out and every maintainer has improvised badly.

• Variables. The brand blue is defined once ($brand-blue) and referenced everywhere. Change it once, it changes everywhere. The four-slightly-different-values archaeology becomes structurally impossible, and rebrand projects shed a whole category of grep-and-pray.

• Nesting. Rules nest inside their parents, so the stylesheet’s structure mirrors the document’s. Legible in a way flat selector lists never were. With a discipline flag we will raise below.

• Mixins. Reusable pattern blocks, written once and invoked by name. The clearfix. The button treatment. The vendor-prefix stacks that CSS3’s transition era multiplies. The copy-paste patterns that drift apart over time stop drifting because they stop being copies.

• Partials and imports. The codebase splits into logical modules (typography, layout, forms, components) that compile to one efficient file. Organization for humans, a single request for browsers. The tension our performance checklist has always managed by hand, dissolved.

• Arithmetic. Grid math computed rather than hand-calculated. With the fluid-percentage layouts our responsive work now demands, this has gone from cute to essential. The proportions Marcotte’s technique requires are exactly the sums you want a compiler checking.

The costs, honestly billed

A year in, the tax schedule. The build step is real. Stylesheets must compile before deployment. One more moving part, one more thing to document, occasionally one more thing to explain to a host or a client’s IT team. The tooling has matured to near-invisibility, with watchers that compile on save. But ‘near’ is not ‘fully,’ and the workflow change is genuine.

Debugging crosses a translation layer. The browser reports line numbers in the compiled CSS. Your code lives in the source files. The mapping is usually obvious and occasionally is not.

Onboarding has a curve. Small, since SCSS syntax is a superset of CSS, so existing knowledge transfers and existing files port unchanged. But a curve, and contractors or inheriting teams need the note in the handoff documentation.

And nesting invites its own pathology. Novices nest six levels deep because they can, generating bloated selectors and specificity wars. Our house rule, nest shallow, three levels as the smell threshold, went into the standards document within the first month. It belongs in yours on day one.

Adopting on a living codebase, without the rewrite

The adoption question teams actually face is not greenfield. It is the living site with three years of accumulated CSS. Here the SCSS syntax choice merits its keep operationally. Because valid CSS is valid SCSS, the migration path is rename-and-proceed, not rewrite.

Our pattern from the conversions we have run: rename the existing stylesheets, establish the compile step, and refactor opportunistically. New work written in the full idiom. Old code converted when a task touches it anyway. Variables extracted first, since the brand palette and type scale migrate in an hour and immediately start paying. Mixins second. Structural reorganization into partials last, and only as sections come up for other reasons.

Resist the dedicated conversion project. It is exactly the modernization-as-cost-without-feature spending we advise against, and the opportunistic path reaches the same destination while shipping client value the whole way.

Six months in, our oldest converted codebase is perhaps forty percent idiomatic Sass and one hundred percent compiling. The forty percent is precisely the parts that change often, which is the only forty percent that matters. Refactoring follows heat. Let it.

And commit the source files, not just the compiled output. The version-control note that sounds obvious until an inherited project teaches otherwise. The compiled CSS is an artifact. The Sass is the codebase. Handoff documentation should say so in bold.

Sass or LESS, and does it matter

The partisan question, dispatched briefly: both are good, and the differences are real but second-order. LESS runs in JavaScript and reads slightly closer to plain CSS. It can even compile in the browser, which is a demo trick, not a production pattern. Sass’s SCSS syntax matches CSS exactly at the base and brings the more powerful toolkit at the edges, plus the Compass framework’s growing library of ready patterns.

We chose Sass for the toolkit depth and have not revisited. Teams choosing LESS for its gentler surface are making a reasonable call. The choice that actually matters is the meta-choice: adopting a preprocessor and the conventions around it. The failure mode that actually hurts is mixing dialects across projects. Pick one house-wide, write the conventions down, move on.

Where the calculus lands

The tilt is team scale and time horizon. Sites maintained by rotating hands over years, which describes most institutional websites and every property this agency touches, collect the maintainability benefit continuously. Consistency enforced by structure. Changes localized by variables. Patterns shared by mixins. The archaeology simply not accruing.

For those properties, our recommendation is unambiguous, and preprocessor fluency has joined our hiring rubric.

For the brochure site touched twice a year by one person: plain CSS remains perfectly respectable. Adding a build step to a project that will never feel the team-scale pain is process for its own sake, a vice we oppose in every form.

Tools should earn their complexity. This one does, precisely at the scale where the pain lives. And given where our responsive work is taking layout math, we would rather have the compiler on staff before the sums get harder. They are about to.