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.
Should I choose BEM or SMACSS? What about ITCSS, ECSS, or a myriad of other options? What about these CSS-in-JavaScript options? How do they all differ, and what are the pros and cons of each?
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
File structure refers to how you divide your scss into styles.
For file structure, I recommend a simple structure that looks something like.
app.scss # top level, @imports and @includes all other files
_variables.scss # file for setting global variables and settings
utils/ # Folder for shared utility functions and mixins.
components/ # Folder for component level styles
pages/ # Folder for page-specific stylings and overrides
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 pages/_page-name.scss.
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
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.
P.S. — If you’re interested in these types of topics, I send out a weekly newsletter called the ‘Friday Frontend’. Every Friday I send out 15 links to the best articles, tutorials, and announcements in CSS/SCSS, JavaScript, and assorted other awesome Front-end News. Sign up here: https://zendev.com/friday-frontend.html
Top comments (0)