Skip to content

Instantly share code, notes, and snippets.

@alanbsmith
Created October 19, 2022 23:14
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save alanbsmith/e5b9fad745161e2b61d72dbe0d0cb79c to your computer and use it in GitHub Desktop.
Save alanbsmith/e5b9fad745161e2b61d72dbe0d0cb79c to your computer and use it in GitHub Desktop.
Some brief styling thoughts

On CSS-in-JS

Overview

This is not an argument for or against any particular library or solution for styling UI. Instead I’d like to bring a bit of context and nuance to the conversation in a way that doesn’t add to the ongoing flame war.

First-Gen CSS-in-JS Wins

There are some things Emotion and Styled Components do very well, especially considering the styling landscape when they was created.

  • variables
  • controlling insertion order
  • scoping styles
  • guaranteed unique (often hashed) class names
  • de-duplicating and removing unused styles
  • dynamic style updates
  • colocation
  • simple type support

At the time, this was huge. And that should be evident because so many teams were willing to pay the runtime cost to have access to those features.

CSS Advancements

CSS has improved drastically in recent years, and I’m absolutely thrilled many of these items are supported natively. There has never been a better argument for vanilla CSS. I think it’s very fair to look at today’s landscape and consider whether CSS-in-JS still makes sense for your context, but it is a clear case of hindsight bias to say it never made sense. You also get some of the benefits that have always existed for traditional stylesheets.

Next-Gen CSS-in-JS Wins

The next generation of CSS-in-JS libraries have far outpaced their predecessors. They have mostly focused on reducing the runtime cost (in some cases to zero) and leveraging many of the advances made by native CSS. Because of that, it’s not a fair comparison to lump them along with their predecessors. Reducing the runtime cost while keeping the majority of the benefits is a massive accomplishment, and they’ll continue to be relevant and viable options for teams.

Remaining Native Gaps

Should you choose a native styling solution (which is great!), you will likely still have to find a way solve a handful of the issues:

  • controlling insertion order
  • dynamic style updates
  • theming
  • type support

There are certainly ways to support those features natively, but there’s no library handling the details for you. It also means you might need to rely on formal convention where everyone agrees to learn and follow the same rules so the whole system continues to work as intended. Will CSS eventually close these gaps? Given their current pace of advancement, I would say absolutely! I’ve never been more excited about where CSS is heading.

Conclusion

I don't see any inherent conflict in these approaches. Both are advancing how we style UI. And while so much has changed, the core strategy remains:

  • Consider your own context and tradeoffs instead of accepting prominent Internet opinions
  • Decide which set of problems you’d rather solve
  • Build with the understanding you’ll need to continuously adapt your mental model as the ecosystem evolves
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment