Global Styles Should be Avoided

Ben Lorantfy
3 min readJul 14, 2019

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:

These are just a few examples, but there’s many more solutions out there. They mostly fall into two categories:

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

--

--

Ben Lorantfy

A software and web developer who likes solving problems with code, math, and design 🇨🇦