Why We Use Styled Components at Decisiv

and why you might consider it as well


It surprisingly led to some good discussion in this thread:

Thread on why CSS-in-JS makes sense

Unfortunately Twitter is not ideal for providing context and longer explanation, and I thought this might be a good way to follow up. Given that, a lot of this article describes what led to our decision to use CSS-in-JS, and provides specific reasons for choosing Styled Components further below. I hope what follows is useful for you and your team.


I Don’t Hate CSS

Styled Components Isn’t the Right Choice for Every Team

I’m also not saying CSS-in-JS is right for your team. Styled Components works really well for us, and I’d like to share why and how.

A Little History | The Early Days of React

Evolving Ideas and Implementations

When React was first announced it seemed so backwards. Colocating JavaScript with markup? Haven’t we proven this was a bad idea? What about separation of concerns?

As it turns out, the idea wasn’t bad, but the implementation needed improvement. React provided the tooling to prove the concept. As more people began using React, we realized that JavaScript and markup have the same concern and there are a lot of benefits to colocation.

Style Management Patterns

But the problem of managing global styles remains. If you’ve been working in frontend for any time at all, you know that managing styles, especially at scale, is really challenging. BEM, SMACSS, and other CSS patterns provide a lot of great guidelines for managing styles. But guidelines only go so far. And as your application grows, it becomes more difficult to avoid unintended side-effects. Mark Dalgleish has a great talk on CSS-in-JS and says this much better here.

Enter CSS-in-JS

As Glamor, Glamorous, Styled Components, Emotion, Aphrodite, etc. became available, they created a surge in popularity for colocating styles. Our implementations finally caught up the the concept. Similar to colocating JavaScript with markup, the idea of colocating styles wasn’t flawed, rather our previous tooling was inadequate. We are now able to stand at a vantage point where we can see the benefits of the concept.

What’s Next

Our frontend team at Decisiv is solving this issue by building an internal component library. It allows us to version, test regressions, collaborate with our design team, and share our UI across multiple applications. A lot of other teams are doing this as well. Custom component libraries were once reserved to large dev shops and thought-leaders. But as our tooling improves, I see more teams building their own internal component libraries. Design and development is becoming less of a handoff and more continuous collaboration. (Which is awesome! 🎉)

From my experience, building a component library is the best way to keep UI consistent and predictable across applications, and CSS-in-JS has been the best tooling available to build these libs.

Why We Chose Styled Components

We ❤️ Styled Components

Large & Thriving Community

Template Literal Syntax

Sass Support & Polished

const Link = styled.a`
cursor: pointer;
text-decoration: none;
&:hover {
color: blue;
text-decoration: underline;

Again, writing our styles in this way feels really natural and reduces lines of code at the same time. Along with the basic Sass support, there’s also Polished, a small toolset created by Styled Components to provide additional Sass functionality and other helpful tooling.

Native Mobile Support

We’re Not There Yet

However, I’m encouraged to see the adoption and enthusiasm of CSS-in-JS moving it forward. I’m also encouraged by the dialog between the various lib communities. Those conversations will help establish patterns for best-practices leading us to more consistent and predictable UI.

Final Thoughts

Thanks for reading! You can find me on Twitter and GitHub. If you enjoyed this, your should also subscribe to my newsletter! https://tinyletter.com/alanbsmith

design systems @workday