vanilla-extract VS css-in-js

In our experience, the best testing strategy for modern frontends is a combination of E2E testing (using Playwright+NextJS), and unit testing. Visual regression testing is not worth the effort in our opinion, especially with the advent of better CSS tooling like TailwindCSS and Vanilla Extract.

For building component libraries I’ve been a big fan of vanilla extract. Apparently it’s from the same people who made css modules

This sounds exactly like Vanilla Extract. https://vanilla-extract.style/

KumaUI : Another relatively new contender, Kuma uses zero runtime CSS-in-JS to create headless UI components which allows a lot of flexibility. It was heavily inspired by other zero runtime CSS-in-JS solutions such as PandaCSS, Vanilla Extract, and Linaria, as well as by Styled System, ChakraUI, and Native Base. ### Vue

The components are styled with CSS modules. When building the library, these styles will get transformed to normal CSS style sheets. This means that the consuming application will not even be required to support CSS modules. (In the future I want to extend this tutorial to use vanilla-extract instead.)

I do a lot of UI work and have never understood the appeal of Tailwind. It’s like relearning a new language. Tailwind was released in 2017. Maybe the CSS landscape wasn’t as good back then? Modern CSS is pretty awesome.

I’ve enjoyed using Vanilla Extract https://vanilla-extract.style/. It’s like css-in-js with none of the downsides as everything gets compiled to css.

Nah, I used enough Tailwind to know it becomes a spaghetti mess. I stick with CSS now, and in React I use https://vanilla-extract.style, compile time CSS in TypeScript.

Vanilla Extract is my current choice for the next greenfield project. I would also recommend checking out how and why this team integrated it with Tailwind.

I'm not trying to call a particular org or library out, because I think the ones I've been digging through (and prompted me to write this) are very high quality. It's vanilla-extract (a build-time CSS-in-JS library) and Braid Design System (built on vanilla-extract).

Apart from what has been suggested, there is also https://vanilla-extract.style/.

As you might have realized by now, the front end ecosystem is saturated with tools, and unsurprisingly, tools have been invented to partially solve some of the problems with writing CSS at scale. "At scale" means that many developers are working on the same large project and touching the same stylesheets. There is no community-agreed approach on writing CSS in JS at the moment, and we are hoping that one day a winner would emerge, just like Redux did, among all the Flux implementations. For now, we are banking on CSS Modules. CSS modules is an improvement over existing CSS that aims to fix the problem of global namespace in CSS; it enables you to write styles that are local by default and encapsulated to your component. This feature is achieved via tooling. With CSS modules, large teams can write modular and reusable CSS without fear of conflict or overriding other parts of the app. However, at the end of the day, CSS modules are still being compiled into normal globally-namespaced CSS that browsers recognize, and it is still important to learn and understand how raw CSS works.

There are a myriad of CSS-in-JS tools, many of which are zero-runtime giving you all the benefits of authoring in a single file without the drawbacks of inline styles. That's how I prefer to do my CSS with React anyway... Vanilla Extract and/or Linaria are my current favorites.

One thing I think you're really missing is what the output is of CSS-in-JS. There are tens of CSS-in-JS frameworks that can output anything from: CSS Module like classes (Linaria, Vanilla Extract), Atomic Classes (StyleX, PreStyle), to the more traditional (Styled Components, Emotion) many with zero runtime cost (ie no JS bloat). That's why I say CSS-in-JS is primarily about developer experience... the output can often be whatever you want it to be.