Why styled-components? 💅

Evan Jacobs
Feb 4, 2020 · 3 min read

One question I see on Twitter and such often is why a developer should choose styled-components over other CSS-in-JS libraries (and other forms of CSS in general.) Here are some of my thoughts in condensed form:

1. At the end of the day, it’s just CSS

You can choose exactly how you want to write styles, we don’t encourage or enforce any particular syntax. Want to write normal looking CSS? Sweet. Want to write style objects that look like DOM JS inline styles? Right on.

We’ve got your back and will apply the relevant vendor prefixes, etc. All we care about is making it as easy as possible to write CSS that is nicely isolated per-component, while still preserving the full power of the cascade when you want it.

2. We focus extensively on developer experience

For me, this is the big differentiator between styled-components and competitor libraries in the same space. Instead of a plethora of packages to download and consume, all of the core library and most popular pieces of functionality are available right in the main import. This makes the library easier to refactor, teach, and ultimately understand.

Further, we spend a lot of thought and effort on implementing helpful dev-time warnings and useful production errors to help you avoid falling into performance anti-patterns. Do we get it right every time? No, but no other competitor library is putting in the same amount of consideration.

3. Performance is a feature, and we’ve consistently raised the bar every release

You could say we’re mildly obsessed with performance. Generally speaking, we will never ship a release that meaningfully degrades the performance of our library and we spend a large amount of time benchmarking and tweaking to ensure the library is both fast and as small as possible for real-world use cases. The v5 release blew past most of our competitors in fact.

4. We are very careful and deliberate about shipping API changes

An extension of point two but worthy of elaboration, the styled-components team is hyper-conscious about our API, how it’s used, and being extremely cautious about introducing changes until we’re sure they are the correct solutions that will work for both power and casual users. This means that when you write code using styled-components you can rest assured it’ll continue working and require minimal refactoring over time as the library evolves.

If for some reason we do change something, we will add ample notice via dev-time warnings and, whenever possible, offer automated “codemods” to make refactoring as painless as possible.

5. We’ve got an amazing, robust community

As I type this, styled-components has more than 5.7M monthly downloads from npm, over 27.8k stars on GitHub, and hundreds of open source contributors. We’re here to stay.

If you’ve used styled-components, thank you! We welcome all contributions and love hearing from our community. As a reminder, the library is not sponsored by any big companies and is entirely driven by volunteer effort; any financial contribution you can make or encourage an employer to make would be fantastic and help facilitate further development in the space.

Thanks for being you and stay stylish 💅
with ♥ ️from the styled-components core team

💅 styled-components

Visual primitives for the component age.

💅 styled-components

Visual primitives for the component age. Use the best bits of ES6 and CSS to style your apps without stress 💅

Evan Jacobs

Written by

Poetry, tech, other pursuits. 🏳️‍🌈

💅 styled-components

Visual primitives for the component age. Use the best bits of ES6 and CSS to style your apps without stress 💅