What to use for React styling?

If you use React, then at some point you've thought about how to style your components.

You were probably optimistic about finding the perfect approach... and then became dismayed when you slammed your face into this wall of style tools:

Some are more popular than others, but for each one you'll find several experts recommending it.

Even worse: it's not about picking just one. Many of these tools can be used together.

Each of these has its own advantages and disadvantages, and I know you don't have time to research every single one. Let me be your guide!

Overview

Before you can find the perfect tool(s), you'll need to understand what they all do and which ones work together.

First we'll break down these tools into four types. Then I'll explain what each of these types actually do.

Then we'll walk through a decision tree so you can decide which tools to use. I'll list out the pros/cons of each decision in the tree.

Finally I'll discuss how the tools can be combined and list some popular combos.

Once you've finished reading you'll be confident that you've picked the best tools for styling your project.

You might be wondering - can't I just use CSS without any special tools?

Of course the answer is yes. You could do that. In fact, if your project is tiny, that might be the right approach for you. You could even just stick a <style> tag at the top of your index.html and put your styles in there.

Sooner rather than later, here are a few problems you might run into:

• You need cross-browser support and you don't like writing out all the vendor prefixes.
• You have trouble finding and deleting unnused CSS over time. (Dead Code)
• CSS rules are applying to elements in ways that you did not expect. (Global Namespace)
• You want variables, nesting, or composition.

All of the above problems are easily solvable with the right tools.

Remember that wall of style tools? To understand it better, I've broken it down into 4 categories: methodologies, preprocessors, postprocessors, and inline style helpers.

Methodologies are guidebooks/instructions on how to use CSS.

Methodologies help you avoid common mistakes by following standardized patterns. They provide suggestions on how to name files and classes.

Example Methodology: BEM

BEM suggests using a particular format for classnames: 'block, element, modifier'. BEM suggests never using nested selectors.

// BEM says bad
.form .button {
  background-color: blue;
}

// BEM says good!
.form__button {
  background-color: blue;
}

CSS Preprocessors are tools that take a some non-CSS language and convert it into CSS.

Most preprocessors use a language that is similar to CSS or an extension of it.

The goal of a preprocessor is to provide a syntax that has more features, is more readable, or requires less typing.

Example Preprocessor: SCSS

SCSS is an extension of CSS. CSS is valid SCSS, but not the other way around.

This example showcases 2 common SCSS features: variables and nesting.

/* input: scss */
$fur: orange;
.cat {
  background-color: $fur;

  .paws {
    color: white;
  }
}

/* output: css */
.cat {
  background-color: orange;
}
.cat .paws {
  color: white;
}

CSS Postprocessors, or just 'CSS processors', modify CSS.

CSS in and CSS out might sound pointless, but processors may be the most useful type of tool mentioned here. They can be chained together, layering features on top of features. When you set up your project this way, you can start simple, and then add more processors later if/when you need them.

PostCSS is the tool that helps you chain processors together - the PostCSS docs refer to each processor as a 'PostCSS plugin'.

Example Postprocessor: Autoprefixer

Autoprefixer is an incredibly useful processor. Using it is a no-brainer if you need cross-browser support.

Autoprefixer adds vendor prefixes to your CSS so you don't have to. It can be used on it's own or as a PostCSS plugin.

/* input: no vendor prefixes */
.box {
  display: flex;
}

/* output: vendor prefixes added */
.box {
  display: -webkit-box;
  display: -webkit-flex;
  display: -ms-flexbox;
  display: flex
}

Inline style is an approach to styling that avoids CSS altogether. It is for those who believe that form and function should be specified together as one.

While using inline styles does have some advantages, it also sets you back immediately in other areas. Media queries and pseudo-classes for instance are no longer available to you.

That's where inline style helpers step in. These are tools that add back in the features that you were missing. Radium is currently the most popular of such tools.

Now that you know what all the tools are, you can start to think about which ones you'll use.

Follow the tree and collect tools as you go. Below there is more discussion to help you decide.

Read on for discussion on each fork in the tree:

Inline Styles?
If you choose YES to inline styles, pick an inline style helper and you're done. The 'inline style' approach does not work with any preprocessors, postprocessors, or methodologies.

Preprocessor?
If you want a preprocessor, check out the home page of each one and see which syntax appeals to you the most. One advantage to skipping this step: one less language your team has to learn.

Postprocessor?
Autoprefixer is a no-brainer for cross-browser compatibility. cssnext is good if you decided not to use a preprocessor, because it provides some of the same features. Use PostCSS to chain together your postprocessors. There are too many PostCSS plugins for me to list them all here.

Methodology?
My research suggests that BEM is the most popular methodology, so look at that one first. Don't use a methodology if you are using CSS Modules. Methodologies suggest class naming conventions, and CSS Modules pick class names for you.

One of the trickiest things about picking a set of tools is that some tools don't do exactly the same thing, but can still replace each other.

For instance, PostCSS isn't a preprocessor, but most people don't use a preprocessor if they are using PostCSS. You can accomplish many of the same goals with PostCSS plugins that you would accomplish with your preprocessor.

Here are some combinations that make sense, along with reasons why you might pick that combo.

1. SCSS + Autoprefixer: You want mature, stable tools. Global styles are OK.
2. SCSS + Autoprefixer + BEM: Same as above, plus you want a convention to follow for class names and organization.
3. PostCSS w/ Autoprefixer & cssnext: You want cutting edge, modern tools. You want to write 'pure' CSS, but with features not yet supported by all browsers. Global CSS rules are OK.
4. CSS Modules + PostCSS w/ Autoprefixer: You want cutting edge, modern tools. You want to write 'pure' CSS without any extra features, but CSS rules should be local.
5. CSS Modules + PostCSS w/ Autoprefixer & cssnext: Same as above, but you also want to be able to use new CSS features before they are well-supported by all your browsers.
6. Inline Styles + Radium: You want to write your styles in JavaScript, in the same file as your React components.

Here are some of the most popular tools based on GitHub stars. This graph also gives an indication of how old each tool is.

SASS/SCSSLessStylusRadiumPostCSSAutoprefixerCSS Modules

Less has the most stars - but PostCSS is trending upwards fast.

I wouldn't have written about all these different tools if I thought there was one, best, way.

Some people prefer to stick with proven, mature tools. If that's the case, you can always use Less or SCSS and move on. Many developers like using a single tool and aren't bothered by global styles.

I personally am more excited by the newer, more modern tools that are gaining traction: PostCSS, cssnext and CSS Modules.