The 80-20 Approach to Sustainable SCSS
There's been a ton of innovation in the CSS and SCSS worlds over the last few years. A multitude of new naming conventions, architectural choices, and advanced libraries to make your CSS more manageable and powerful than other before.
This is great! But the flip side of it is that with additional options comes additional complexity, and for new CSS developers or those who have not been keeping up with every new approach, it can be hard to know where to start.
The complexity of the decisionmaking can be so offputting that you make no decision at all.
80% of the value, 20% of the work
For the vast majority of developers and projects, you don't need to optimize everything to the max.
You should be using SCSS of course, because it is a clean superset of CSS that allows you to do clean decomposition and code reuse.
And beyond that, you can get 80% of the benefit with 20% of the work by making decisions in just two areas: file structure and naming convention.
File structure refers to how you divide your scss into styles.
For file structure, I recommend a simple structure that looks something like.
The app.scss file becomes your entry point to all of your styles. It should import _variables.scss, your dependencies (sounds like largely bootstrap, but also any other scss libraries you happen to use), then your utils, and then your component and page styles.
Organize styles for each component into a specific file for that component. For example, if you are extending button styles you should have a file named ‘components/_button.scss’ containing those styles.
If you have page specific overrides and styles, those should go into
As much as possible, styles should belong to a component or a page, but you may also want some a high level ‘_layout.scss’ file for global styling.
Naming convention refers to how you name your classes.
There are quite a few options for naming conventions, and which one you want to pick can depend a lot on team and project size. For large projects and large teams you’ll want more stringent naming conventions, while for smaller projects and teams you may not care as much.
In the end, the high level is you want your naming conventions to be consistent across components, and you want to keep your specificity low. Many naming conventions strive for a “single class API”, meaning that all styles are at specificity 1 and contained within a single class. I typically allow for some level of modifier classes, but try to keep specificities at 2 or below. (IE at most 2 classes).
Probably the most widely used naming convention is Block-Element-Modifier (BEM). It can feel a little intimidating at first, but is a very good choice. If you’re looking for something a little less rigorously intensive, SMACSS is a pretty good guideline.
Any system is better than no system
The most important thing is not to have a perfect system, but to have a system at all. Enforce consistency in your SCSS organization and naming conventions, and incrementally improve as you learn and find places your current system isn’t working.