There are a lot of different tools out there for styling React components. I’m not going to go into them here, there have been tons of great articles on that.

Instead the more interesting thing is how they all deal with sharing styles. I’m going to quickly go over a few of the different techniques used, and then view them through the lens of cross-compatibility and maintainability.

Old school CSS

Even with all of these fancy libraries, it is completely possible to just use plain old className s and a CSS stylesheet in your project.

Your CSS file is completely separate from your React components, which means there’s no real cohesion between the React components and your styles.

Inline CSS

React gives you the option of inlining your styles using <Component style={object} /> . This tightly couples your CSS style declarations with your components. There are no class names to worry about.

Inline CSS Plus

Radium, React Style, and JSS seem to fall into this category. They all use objects to represent CSS declarations and inline the CSS like above, and then use additional functionality to let you use pseudo selectors and media queries.

Styled-components takes a bit of a different route. It binds your styles to reusable components instead of the component you are working with itself.

CSS Modules

One of the last solutions is using CSS modules, which lets you use CSS (or SCSS if you set it up) files and reference their class names in your JavaScript:

import { wrapper, button } from './Component.scss'; export default () => (

<div className={wrapper}>

<button className={button}>Click Me!</button>

</div>

);

Of all the libraries, styled-components is probably my favorite, but it doesn’t address some of my concerns:

How do you share styles outside of React?

If you are building a small web application, or a few individual widgets, then sharing between different platforms might not be a big concern. But if you have multiple platforms, each with their own technology stack, how do you plan on sharing styles between those different stacks?

Let’s say you are going to build a static website, since there’s absolutely no need for React, you go with a simpler stack so your designers and marketing team can update it and maintain it. If you wanted to share the styles for buttons that you made using any of the “Inline CSS Plus” options, you are out of luck. There is no way to share that button’s styles.

Or if you are a company that already has brand guidelines, with developers and designers who work on maintaining reusable design patterns using CSS and HTML, how are you going to keep your React app up to date using Inline CSS or Inline CSS Plus?

How easy to maintain are these different solutions?

I like the way styled-components makes you turn your CSS into re-usable components. It’s also very cohesive — the CSS is right there next to the component, since the component is just a tag for your CSS string. But it does not help you share your styles with other technology stacks at all.

On the other hand, SCSS makes it easy to maintain your styles across many different technology stacks. All they have to do is import your SCSS library. But the thing about SCSS is that it doesn’t have any HTML in it, you have to document how to use your SCSS.

We Still Use SCSS

Even after all these great React styling libraries have come out, I still use SCSS. That’s because SCSS lets me share variables, scaffolding, media queries, classes, hover effects, and styles efficiently between different code bases.

If a website is built on Jekyll or Hugo, I can still use the same SCSS library to build the site off of and still adhere to brand colors and guidelines. If the webapp uses React, I can use CSS modules to import my SCSS classes and still get to use the media queries and pseudo-selectors without having to do global declarations.

When it comes down to it, the best part about SCSS is that it doesn’t lock us into any technology other than SCSS. With the majority of the React styling libraries, not only are you locked into React, but now your styling is too. All that lose just for the sake of cohesion between your components and your styles.