About Scaling CSS
Building a web app is far from easy and your code can quickly become messy as you add new features and iterate. How can we solve that?
CSS is simple, but tough
While building a web app, you first code a prototype or a MVP that becomes a beta version, then a light version of the app which grows and grows. Eventually you start hiring developers and you realise your code is crap because you never took the time to refactor it as a whole.
CSS is simple at the beginning but becomes messy if we don’t take care of it. It is hard to scale from the start without a good study of what the product will look like in a few years. Stylesheets are more and more difficult to maintain and become heavy with a lot of repetition and !important. That’s where bugs begin to appear and are more difficult to resolve than the precedent ones.
Code better stylesheets
We hired our first front-end developer a few months ago, which meant someone else was going to work within my stylesheets, my very messy stylesheets. For a while he simply called me when he didn’t find his way through my code and I’d help him. The thing is we both lose time between messy code lines and bad architecture.
Furthermore it’s inconfortable to work on something you have to check constantly, you should be able to trust your code. CSS becoming quickly difficult to maintain, if it is not well organised you have to see what you’re actually doing and if your work has been taken into account. A better architecture can solve this problem by arranging stylesheets in a meaningful way.
You should be able to trust your code.
Then the question of naming convention is important too since it’s easier for several developers to code together if they know what the others are doing and how they’re working.
Organising the mess
The problem is set, now I have to convince my associates that the time I’d invest in rebuilding our CSS architecture is worth it. Actually that was quite easy to do since it deeply affects our ability to scale our development process.
Then we have to figure out how to do that, how much time it is ok to spend on it and how it will be valuable in the future, meaning what are the deliverables.
Of course it is clear that research phase is important here. We have to document it and draw conclusions based on quality documentation. I think of this research as work people have already achieve as well as living discussion around the subjects on forums or groups. My experience with bad CSS will also help me not to make the same mistakes.
As every idea is nothing without execution, we need to deliver something to build a base from which we’ll be able to scale. Our deliverables consist of a SASS architecture defining folders and stylesheets in a meaningful way for future developers and for ourselves. Naming convention has to be written down in a document explaining how it works, the doc. Indeed, people who aren’t part of the reflexion won’t understand by themselves why we chose to do it that way. By explaining to them the how’s and why’s, they’ll be able to understand the value of it and maybe realise it is an approach that suits their development process.
A new hope
As I said, the purpose of this work is to produce scalable and adaptative code. We expect the outcome to solve two main issues. The first one is to maintain CSS more easily than before and the second one being to write clean code that other developers can quickly understand.
Personally speaking, I also see this work as my contribution to the web. That’s why I intend to share my researches and outcomes. This article is actually the first of a series I’ll write about scalable CSS and its role in web development. A repo on Github is created as an embodiment of this work and I hope you’ll join me in building a better CSS development methodology.
We can do it
In conclusion, maintaining CSS is tough. It is ok to ship fast code for a prototype or a beta but as the app starts to scale, it is time to architect it in a way that is scalable.
So what now? Well, a lot of resources and methodologies already exist. Check SMACSS, ITCSS or OOCSS for architecture and BEM and its variants for naming convention. Can it fit your development process? Maybe you should adapt it a little bit or even think of your own CSS guidelines. Actually that’s what I’m currently working on.
Every project is different and in our case at Koalect we have to build an extremely modular CSS. We craft fundraising platform for a lot of different clients on top of our own so our design system is adapted to each one of them. That means we have to build a lot of patterns and think in systems instead of pages.
Please come and join me in this open-source adventure on Github.
And if you’re writing about design or web development, join our publication here.
