Spectrum is now read-only. Learn more about the decision in our official announcement.


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


Emotion vs Styled Components

December 17, 2019 at 6:29pm

Emotion vs Styled Components

December 17, 2019 at 6:29pm
Hi everyone! I’m trying to pick a CSS-in-JS solution for my app and I’m having a hard time picking between Emotion and Styled components. Can you please help me understand why I would want one over the other? Also are there any comprehensive video courses or tutorials that covers all of the Emotion features? I have found the resources for styled components to be much easier to find, so it’s been hard to compare.

December 17, 2019 at 7:41pm
Currently both libraries have the same functionalities. Luckily, both styled-components and emotion have been feeding on the functionalities that each library has been implementing. Both libraries can use components with styles or encapsulate the styles and apply them to html tags. At performance level, the styled-components v5.0 rc2 is ready, it is in beta mode, it will soon be ready! styled-components v5 becomes the CSS-in-JS solution with all the features it brings faster. You can see more info here:
The documentation of styled-components is very extensive and especially the amount of resources you can find to work with this library. In the end styled-components is much more widespread and it is easier to find resources and solutions to your problems.
Also, understanding that your application will be based on React, you also have styled-components for react native in case your application scales and you need to have a native app, you would not have to decide which method to give styles to use, you would not have to change context .
Also, as a good thing, if you decide to use a library and later want to change it, you can do it progressively. In addition, the syntax is very similar and it will not cost you much to do it.
Interesting! Thanks so much Juan!

December 18, 2019 at 3:29am
Until [email protected] is officially released, Emotion is marginally better: smaller bundle size and faster runtime.
In terms of features, Emotion is better because it is modular (not only React/RN) and can be customized and tweaked to suit your needs. [email protected] adds some customization features, but isn't released yet.
The main reason for my personal preference and recommendation to choose Emotion over SC is source maps support. In Emotion it just works (using the Babel plugin or macro), while in SC it is an open issue since 2016... Emotion's downside is the docs, which are minimal. Also, Emotion's modularity requires one to decipher the multiple packages, which are poorly named and described. :( There's ongoing work to fix that in the next major version though.
Bottom line: apart from source maps, they are very similar and are in constant competition - which is awesome for us users! I've used both and they are great choices :)

December 20, 2019 at 6:45am
Thanks Nick! I really appreciate the insight!

December 23, 2019 at 7:40pm
Our small team has been spread between styled-components & emotion for almost 18 months. Looking forward, performance and functionality differences are, for practical purposes, negligible. Either library can be swapped out for the other with minimal effort.
18 months ago, emotion was picking up momentum and looked like the certain eventual winner, but that hasn't happened. Today, I'd be inclined to start a new project with styled-components, for these two reasons:
1) The styled-components ecosystem is considerably bigger. There are substantially more styled-components based tools, design systems to look at, video training courses, coverage in React books, etc. If you are looking for materials to learn about css-in-js in general, I'd wager there are 10x the amount that use styled-components than emotion. This fact alone has thwarted our team's previous commitment of moving to emotion.
2) Relative popularity. styled-components remains about 3x as popular based on GitHub stars, activity, npm installs, etc. Popularity on its own doesn't make a library better than another, but if 2 libraries are more or less equal in all other regards, higher popularity equates to lower risk.