DEV Community

loading...
Cover image for Why Most CSS Methodologies Don't Work At Scale

Why Most CSS Methodologies Don't Work At Scale

Daine Mawer
Lead Frontend Engineer
・4 min read

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

http://getbem.com/

...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.

https://rscss.io/

...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

http://smacss.com/

...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.

Discussion (8)

Collapse
jfbrennan profile image
Jordan Brennan • Edited

Interesting read, I really like point #2.

I hesitate to share this because I haven’t finished the “official” doc, but it seems like this topic interests you so I’m happy to share prematurely.

I’ve had a lot success at large and small companies following a methodology I call TAC: Tag, Attributes, then Classes. It’s a hybrid methodology where the HTML constructs of tags and attributes are embraced and fully leveraged in order to create a system that can scale in both directions (examples include two large companies with diverse web project types and tech stacks with globally-distributed teams all the way down to a tiny AI startup).

Long story short, you first exhaust all native HTML and target those tags (and any necessary attributes, e.g a[download]) with whatever styles are unique to those components. Then you create custom components with custom HTML tags and prefix those custom tags with a valid Custom Element prefix you choose (I use “m-“). These are NOT Custom Elements though, not yet anyway. A good example is an icon component. HTML doesn’t have this natively, and following the TAC methodology you do not create classes for components (only utilities, more on that in a second). The icon component would use a custom tag and attribute like this: <m-icon name="phone">. Like native tags, CSS would be use to apply this component’s unique styles. Other native attributes are still applicable and work as expected, e.g. <m-icon name="phone" aria-label="make a call">.
These custom tag components have a clean and meaningful API just like native elements and their markup looks nice and uniform when mixed in with native tags. TAC’s key to scaling that no other methodology has is that by requiring the use of custom tags instead of classes these components can evolve into true JavaScript-enabled Custom Elements without breaking changes or shifting API paradigm. All component types have the same standard HTML interface regardless of implementation (native, styles-only custom tag, or Custom Element).
Ok, so far all components have had only their unique styles implemented and those styles get tied to their API, i.e. their tags and attributes. Generic styles, like margin, padding, font size, and even things like border, background, and display, are applied via utility classes. This approach does wonders for keeping components true to their original design while permitting lots of modifying styles to be easily added and removed all while managing the specificity scores better than any other method I have tried.

There’s lots more details, but that’s the idea.

Collapse
dainemawer profile image
Daine Mawer Author

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!

Collapse
jfbrennan profile image
Jordan Brennan • Edited

Just custom tags and Custom Elements, not full Web Components. The hairy parts of Web Components are avoided.
The methodology works well for big apps as well as static sites. Have seen it used alongside Ember, React, Vue, Riot, and jQuery codebases. Compatible with everything since it's standards-based. Been pretty ideal too for the design systems I've worked on.

Collapse
honatas profile image
Jonatas de Moraes Junior

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.

Collapse
aalphaindia profile image
Pawan Pawar

Interesting!! :)

Collapse
chakudi profile image
Vaishali JS

Its rare to find such interesting insights about CSS methodologies! 👏👍

Collapse
westcoastkraken profile image
westcoastkraken

Helpful, as well as a great read. Thank you!

Collapse
dainemawer profile image
Daine Mawer Author • Edited

I'm very glad to hear that! Thanks @westcoastkraken !

Forem Open with the Forem app