Global Styles Should be Avoided
If you’d like to read this article on my website, click here
Over the last few years working in front-end software development, I’ve noticed several anti-patterns that can be detrimental to applications, and hard to reverse. This is the second article in a series of opinionated posts about front-end anti-patterns that should be avoided. You can read the previous article here.
The Anti-Pattern
The general consensus of the programming community is that global variables are just bad.
- Breaks encapsulation
Any function or piece of code that uses global variables can be broken by other pieces of code. As soon as you use a global variable, you have no idea if that global variable will break your code. - Poor readability
A piece of code is easier to understand when there are only local variables. You don’t have to identify if something is a global variable, you don’t have to go find where it’s defined, you don’t have to go everywhere it’s used to see what it’s purpose is. - Breaks information hiding
Global variables break information hiding and all the benefits that come with it. If the main goal of programming is to manage complexity, a good way to achieve this is to break it up and hide away complexity into manageable chunks. - Namespace pollution
Global variables are accessible everywhere, which means they can conflict with anything else.
So if most of us agree global variables are pretty detrimental to a program, then why did we decide global styles are ok? They have most of the same issues:
- Breaks encapsulation
Global styles are not encapsulated. This means if you change a global style, it can have global impacts. You’d have to check every usage to make sure everything still looks fine. - Poor readability
When you come across a global class name, you have to go figure out where its defined in order to understand the code. - Breaks information hiding
Global styles are not hidden information. This means it’s hard to hide away the complexity of them. - Namespace pollution
Global class names are accessible everywhere, which means they can conflict with any other class name.
While unfortunately global styles are ingrained into the language of CSS itself, many people have come up with workarounds:
- css-loader
A webpack loader that compiles local class names into globally unique ones. Only works if you’re using webpack. https://github.com/webpack-contrib/css-loader#scope - styled-components
styled-components is a way to write css without really using classnames, but instead using React component names. It’s also one of my favourite libraries ever. Only works if you’re using React. https://github.com/styled-components/styled-components - JSS
This is like styled-components but not just for React. https://github.com/cssinjs/jss
These are just a few examples, but there’s many more solutions out there. They mostly fall into two categories:
- CSS in JS
Some kind of javascript library that takes CSS written in a JS file and turns it into global CSS. Sounds weird at first but it’s just something you get used to. There’s also plugins for editors to give you back your CSS syntax highlighting. - Build Tool
Some kind of build tool that takes some CSS written for a local component and transforms it into global CSS using globally unique class names. Means you need a build step, but you probably have a build step anyway.
Final Thoughts
Global styles should be avoided for the same reasons global variables are avoided. There’s many alternatives available that enable local styling. Local styling is easier to understand and less likely to break.
This is the second article in a series of opinionated posts about front-end anti-patterns that should be avoided. You can read the previous article about separating state and views by clicking here.
