styled-components VS styletron

You can use Media Queries in Styled-Components similar to how you would use them in CSS, other than the fact that you can define custom screen sizes in your theme and access them inside your Media Queries:

The above is still a more "traditional" way to use CSS. Let's look at a CSS-in-JS example that makes use of styled-components:

As such, a new breed of solution was born — CSS in JS. Mostly prevalent in the React ecosystem, libraries such as Styled Components and Emotion allowed scoping styles to components and in so, got rid of the cascade problem.

Not trying to start a flame war but what can you do with these that can't be accomplished with React and e.g. https://styled-components.com ?

Finally, I came across styled-components which is an awesome library to re-use styles for components. For me, it helps to create much more readable components and no more className inside my code!

styled-components

Testing: react-testing-library, jest Styling: styled-components Form: react-hook-form Tools: EsLint and Prettier

I’ve had good experiences with the styled-components library

Styled components issue for reference: https://github.com/styled-components/styled-components/issues/3856

Over my years of working with React, I’ve loved using CSS-in-JS libraries like Emotion and Styled-components. However, their inherent performance overhead from injecting CSS at runtime and their incompatibility with the latest Next.js features such as App Router and React Server Components (RSC) have always been a nagging issue for me.

Some technical thoughts as someone who could care less about fanboyism:

- One point where atomic CSS frameworks are supposed to shine over conventional CSS is bundle size, since they (at least the good ones) compile to only a single rule for any used value, rather than potentially repeating rules for semantically different classes.

- Another point where atomic CSS frameworks shine is just sheer volume of banging code out. When the bulk of your output is visual, mastering tools based on shorthands like tailwind, emmet, etc can feel very productive.

- Purely atomic CSS frameworks can make some workflows more difficult, e.g. by having too granular call sites and not allowing "let's see what happens to the overall theme if I do this design change" iterative style of work, or because workflows that edit CSS on the fly via browser devtools can no longer be used to limit impact within semantic lines (e.g. "I want to change padding only on buttons, without breaking everything else that happens to depend on the same padding value"). There are both design-oriented and debugging-oriented workflows that are affected in similar ways.

- You generally don't get visual regressions at a distance w/ atomic CSS. This matters at organizations where desire for pixel precision and simultaneously fickle design teams are the norm. But conversely, "can we just change the font size to be a bit bigger across the site" can often run into issues of missed spots. On a similar note, designs may become inconsistent across a site over time due to the hyper local nature of atomic CSS oriented development.

- Custom rules may as well be written in APL[0]; they usually aren't documented and it takes a "you-gotta-know-them-to-know-them" sort of familiarity to be able to work with them (or get back to them after a while).

- There are some tools that mix and match atomic CSS with other paradigms. For example, styletron[0] can output atomic CSS for the bundling benefits, but looks like React styled components from a devexp perspective, and has rendering modes that output traditional-looking debug classes for chrome devtool oriented workflows.

The main theme to be aware of: proponents rarely talk of maintenance, so beware of honeymoon effect. Detractors often omit that traditional CSS (especially at scale) also requires a lot of diligence to maintain. So think about maintenance and how AOP[1] vs hyperlocal development workflows interact with your organization's design culture.

[0] https://www.styletron.org/

[1] https://en.wikipedia.org/wiki/Aspect-oriented_programming

It is created, managed, and utilized by Uber. It includes a wide range of attractive components, with accessibility as the top focus. It is quick since it is built with the Styletron engine. Style overrides can be used to tweak themes, but in my experience, I've never required them because the design vibe they're trying for is precisely what I want.

[0] https://www.styletron.org/ [1] https://baseweb.design/blog/getting-started-with-styletron#getting-started-with-styletron

When we created the library, we were using styletron for our styles, and we wanted to bind the breakpoints we defined in @blocz/react-responsive with the breakpoints used for our styles.