.css files that you
<link> up in the head all on your own.
If you’re curious why anyone would be interested in going the CSS-in-JS route at all, here’s some reasons we discuss in the video:
- Dead code elimination. The only styles that are loaded are the styles for the components in use at any given time. There’s no shipping any unused styles. When a component dies, so does its styles.
- Scoping. Writing new styles cannot affect anything else in other places on the site, so there’s no need to worry about writing a style that has bad or unintended consequences elsewhere due to a selector in the global scope. We get scope protection with naming ideologies like BEM, but it’s not tooling-enforced.
- Worry-free naming. In some cases, there’s no need to pick a class name or ID for what’s being styled since the output is contained UI.
- Developer ergonomics. It can be nice to have styles in the same file (or otherwise very close to) the component itself. In the same way, some developers feel very comfortable in JSX. Also being able to style things without any scoping worry means developers may feel empowered about styling rather than intimidated by it.
- Design system friendly. Design systems are all about components and so is React. These complementary modes of thinking align quite well with one another.
And that’s not everything, but you can see why it’s compelling to some people. It has certainly inspired lots of discussion. Why not when it offers all those benefits? Well, it’s a very different development environment that doesn’t necessarily click with everyone. It requires bending the web platform to do somewhat unusual things and that comes with warts. Not to mention there is a literal cost to it (size of packages and such) that users pay for, which you’d better hope pays for itself with efficiency.
Dustin went so far as to build out a demo using Sass to style things to compare it with how it can be done with CSS-in-JS, which demonstrates how porting styles looks as well as the possibilities of doing it.