Many Web developers across the World, across libraries and across technologies have agreed that the way to develop maintainable user interfaces is to split concerns into self-sufficient components. The idea is mature and widely known – for example, by mobile devs or those Web devs who had used the web-components-like approach before. Yet, its popularity on the Web has increased during the last few years. Thus, a number of new ideas on handling all the satellite concerns like styling or state management has been presented or adjusted. Today, I’d like to focus on the first one – styling.
I used to favour the approach where one component has one corresponding SCSS file describing its styles. The SCSS file is then imported in a JS file, and then adequately managed by Webpack. This solution has enormous power, mostly due to the Superpower of SASS itself. The only thing you really should take care of that the styles you’re defining for component shouldn’t override other components’ styles. And that’s where the BEM (Block Element Modifier) comes in. If you’re encapsulating your styles in blocks, and naming it after your component, it’s rather unlikely you’ll break the component styles of others. Of course, I’m assuming the component name is unique across the system.
CSS architecture and methodologies to deal with globality
BEM brought many new things into the World of maintainable styles, and widely popularized its naming convention. Thanks to that, if a developer has already had anything to do with BEM, it’s reasonably easy to introduce them to a project where this methodology is used. This hasn’t always been the case in the past, when custom frameworks, a number of not fully developed methodologies and project-specific naming conventions were quite popular. Also, thanks to the direct binding between the JS and CSS file it’s reasonably easy to eliminate dead code. Along with deleting the JS file (or splitting it into smaller parts) we delete or split the SCSS file.
I’ve made an assumption on component name uniqueness. Now, this might be quite easy to achieve if you’re working in small team and a relatively uncomplicated (or simply young) project. The problem with CSS globality is that it might become a bit annoying if you’re intending to place your code in someone else’s codebase. For instance, as some plugin on 3rd party platform, a new feature added to an existing system. Actually, this is the case even if you simply use 3rd party libraries for common components, in which BEM methodology might also have been used.
Going further
Despite all that, I felt like BEM and one SCSS file per component worked fine for me, and the issues addressed above were quite distant. However, I was still curious if I could go a bit further with maintainability and developer experience. I was more than happy to explore the opportunities of CSS modules, CSS in JS and the idea of inline styles in general.
About a year ago, I got hugely inspired by CSS modules co-author Mark Dalgleish. He lit a lightbulb in my head with this powerful talk at Reactive Conf 2015.
Inline styles and CSS Modules
Initially, I was a bit skeptical about things that might not necessarily be applicable to inline styles. I have to admit I didn’t spend too much time on research when I looked at the topic a year ago. I’ve jumped back into the topic quite recently. Back in 2015 I briefly went through a number of articles to check if it would work for my future projects. At that time, even though the Open Source community was doing a great job on developing those ideas to the state of fully functional libraries and tools, I was still more into using SCSS and BEM.
The problems I was mostly worried about were mentioned and addressed by Mark Dalgleish (see the CSS modules talk linked above). He proposed locally scoped CSS modules as an alternative to the hacks and inconveniences that CSS in JS libraries have been struggling with then. With plain-but-scoped CSS you didn’t really have to worry how to apply pseudo classes, animations, compatibility fallbacks, or media queries. Additionally, you got the modularity idea from inline styles for free.
Also, it made the composability of styles tidier than in inline styles. It gets even more powerful with Post CSS and its enormous base of plugins. And that’s just the top of the iceberg. Check out David Wells’ talk to get fully sold on the idea.
So, is it worth it? Definitely, as long as you’re choosing your tools wisely. Much depends on what kind of problem you actually have to solve. I think there are many projects where it’s ok to start small, without tooling around the styling too much. And obviously, there are many projects on a scale I can’t even think of. All these tools and ideas are great and worth spreading. I encourage you to find the tools that suit your needs. Experimenting with them will not only allow you to do your job better and ship your projects with satisfaction. It’ll also let you grow as a mindful developer.
