There is a famous computer science quote:
"There are only two hard things in Computer Science: cache invalidation and naming things." ~ Phil Karlton
"Ensuring CSS scales" should be added to that list. Scaling CSS is an incredibly difficult achievement to unlock, and something we don't always consider when using frameworks or tools.
With the introduction of technologies like CSS-in-JS, CSS Modules, and other Webpack/Node-centric solutions, CSS scalability has become less of a headache. But what if your product or website is not built in React or Vue? What if you're still using precompiled technologies like SCSS or PostCSS in environments like WordPress, Laravel, or custom-built solutions?
As your project grows, you need to start thinking about scaling CSS and how to go about doing that. Most engineers think that they can solve scalability when their project is already quite large, but the truth is that a good scalability strategy is well thought out from the beginning.
As I'm sure most of you are already aware, CSS is not a particularly dynamic language, if you're not careful it can lead to bleeding CSS styles, specificity issues, and hundreds of lines of unused CSS declarations.
As our websites become more complex, scalability moves to the forefront of performance and code management. If you're new to Frontend development in general, you may not be aware of how scalability affects applications, so let's define that:
Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
Okay, that's pretty "computer-sciency".
Let's tone that down a bit:
To scale...means that we structure code in a way that will allow us to grow our application from a good foundation. As our application gets bigger, it doesn't necessarily become more complex, it just retains its best practices as it grows.
This is way more difficult than it sounds.
When speaking to my peers, one statement is always true:
"We start out with good intentions, and almost overnight it feels like the code base becomes out of control and hard to manage"
To mitigate this, a handful of smart individuals have attempted to reign in the somewhat untameable nature of production-ready CSS by writing/conceptualizing about CSS "methodologies".
You can think of methodologies as a set of conventions that you follow that ensures consistency.Here are some of the most well-known methodologies:
1. BEM: Block Element Modifier
...is a methodology that helps you to create reusable components and code sharing in front-end development.
2. RSCSS: Reasonable System for CSS Stylesheet Structure.
...is not a framework. It's simply a set of ideas to guide your process of building maintainable CSS for any modern website or application.
3. SMACSS: Scalable and Modular Architecture for CSS
...is a way to examine your design process and as a way to fit those rigid frameworks into a flexible thought process.
All of these methodologies have their pros and con's and I will not attempt to try and compare them. The most important reasoning behind these methodologies is that they standardize CSS in a consistent way. However, all of these methodologies have one crucial ingredient that no matter how much they prescribe, they can't seem to get right.
Regardless of the methodology, CSS scalability relies crucially on an engineer's understanding and in-depth knowledge of how CSS works. Often foundational principles like Importance and Specificity are overlooked or easily remedied by poor override conventions or the cascading nature of CSS is not fully conceptualized.
In addition to that, here are a couple of reasons why CSS, and any chosen methodology doesn't scale well:
1. Multiple engineers with varying experience.
Considering most projects have a variety of experience levels, from junior to lead, CSS methodologies are often interpreted with the slightest of nuances.
This can cause a fair amount of misinterpretation in the codebase which leads to components being written slightly differently or incorrectly when scaled. This causes headaches with specificity, importance, and overall code conventions.
2. Often there's a lack of an HTML methodology.
CSS Methodologies are far too often looked at without their encompassing HTML foundation. HTML components can be built in a number of ways, depending on the engineer and their experience level.
Some engineers use classes to style, others use attribute selectors to handle state and some do none of the above. This makes styling HTML components in a consistent way a problem before we even begin thinking about scaling CSS.
3. Misinterpretation of rules
One of the biggest culprits in CSS methodologies is the misinterpretation of concepts. I've seen this happen often, especially in code reviews where engineers haven't quite grasped the core of the methodology. This leads to malformed class names, or poor CSS structure, bleeding styles, and scope creep.
A methodology is like a well-oiled machine and thus each component needs to behave in an expected and specific way in order to do its job in a consistent way.
4. Enlightenment
At some point, in every large project, engineers reach a point where they look at their code and just want to scrap the entire codebase and start again.
As you become intimate with all the working parts of your website and see the unexpected side-effects of minor CSS declarations causing problems in unrelated components, you actually start to get some clarity. I find this to be the most frustrating thing ever.
The reason being is that you begin to see your CSS in a new light. You see where you went wrong, or what you didn't account for and you more than likely could rebuild a better product with less and more "to-the-point" CSS with better hindsight.
In fact, at this point, you begin questioning the need for a CSS methodology in its entirety.
Conclusion
This article was not written to dissuade you from using a CSS Methodology. In fact, I think it can be incredibly useful (if done correctly).
That being said, before starting a project make sure you educate your engineering team on the ins and outs of the methodology you choose to run with. If the entire engineering team is on board you will see the benefits of scale and not the pitfalls.
Top comments (6)
The most interesting thing here is that this does not apply only to CSS but to any technology. Many people talk about CLEAN and SOLID but these words alone are nothing if not combined with a proper interpretation of the concepts. Very nice article.
Interesting!! :)
Its rare to find such interesting insights about CSS methodologies! 👏👍
Very interesting approach. I like the idea of approaching styling through a more foundational implementation of Web Components. I do wonder how much extra work it would require to set up Web Components for a large site though? Regardless, sounds like you're on to something. Definitely send me the link when the docs are ready!
Helpful, as well as a great read. Thank you!
I'm very glad to hear that! Thanks @westcoastkraken !