A year ago a friend called me and said: “Hey man, wanna try working for Microsoft?”

Well why not. Not as they’ll ever consider me anyway. Fast forward 8 months, 2 phone screens and 6 interviews, I found myself sitting in the office at Oslo, with two big monitors staring at me, and a not-so-tiny gut feeling of “what am I supposed to do now.” At least I knew my name: Jakob Werner. And I was the new guy.

Delve

The product I was going to work on was growing fast. The build process was just switched to using Webpack, React, and Typescript, which made it possible to build new components at a rapid pace. This is when CSS issues started piling up, and ignoring them was no longer an option.

- “You’re that CSS guy, right?”

Seems like everyone knew I was joining. My colleagues helped me feel like part of one big family and directed me to work on the stuff I felt really comfortable with — CSS. I couldn’t wait to start.

So I figured investigating Delve’s CSS would be a good idea. It did have LESS files, but they were actually only CSS files renamed to .less with a few mixins every now and then. We had specificity issues, lots of unmatched colors were still all over the place, classes were clashing with each other and !important rules were overriding something way out of intended scope. These issues had to be addressed. I could finally fix something!

One rule to rule them all

The major concern was that this way of writing CSS collides with “The Rule”: encouraging devs to fall into The Pit of Success. Delve engineers encourage architecture that encourages the right thing to naturally happen: this was a key decision behind React and Webpack. Delve’s previous CSS, on the other hand, was just too easy to fail and break the design of our product. All must follow The Rule, and CSS should not be an exception.

So we started thinking of ways to fix this. Starting was easy — just createvariables.less, mixins.less and animations.less files. Okay, we solved colors, synced some animations and browser special cases, but we still had all those specificity issues.

Then we tried BEM. It didn’t work for us, because we feel a dev shouldeffortlessly write CSS and feel confident about it. Code reviews were helpful, but inefficient and error-prone.

CSS modules

Glen Maddern’s article was a reason to bring cake to the office. If you haven’t read it yet, please do! Using CSS modules we could hash class names to isolate styles from each other. CSS modules spit out a variable which contains the hashed names. So, using JSX, instead of writing:

return <div class="container"> ... </div>;

We could do this:

var styles = require("component.module.less");

return <div className={styles.container}> ... </div>; // generates:

<div class="moduleName-container__1h4ds"> ... </div>;

We just got rid of class name clashing! And this follows The Rule perfectly!

We had a prototype working in no time and proceeded with converting all our components to modules. This made our developers feel a lot more confident in writing code and they no longer needed to worry about class name clashing and specificity. CSS was finally local and isolated to a specific component.