Our approach to CSS and how we chose it

Written by Patrick O'BrienSenior Software Engineer, Tines

Published on April 20, 2021

This article was posted more than 18 months ago.

Recently at Tines, we found ourselves with something of an “evolutionary” approach to CSS. That is to say that while we certainly had CSS and that CSS certainly worked, there didn’t seem to be any master plan or guiding intelligence behind its design.

We had a mix of Tailwind, SASS, CSS modules and healthy doses of inlined styles with no clear guidance on which approach was preferred. This is all perfectly normal and reasonable in the early days of a start-up where there are green fields in all directions and progress is the most important thing.

However, as our team grows and our product matures this sort of cavalier approach starts to have a cost. Most acutely, new members of the team can't tell what the right thing to do is, and will waste time understanding the various options and choosing between them. Also, it’s been my experience that in the presence of two equally acceptable ways of doing things engineers will almost inevitably invent a third.

The scatter-gun approach to CSS also had real-world product implications. We’re asked fairly regularly about adding a dark mode, but with such a scattered approach to styling, it was difficult to imagine doing this without creating an even bigger mess.

Finally, we were shipping what I can only describe as an astonishing amount of CSS to our customers. More on that below.

Picking a CSS Philosophy 

There were really two levels of decision we needed to make here. First, there was a broad decision on which general approach to CSS we wanted to take. There were a few options we needed to pick through here:

1. Inline