Thoughts on CSS-in-JS and Utility-First CSS (Tailwind)

Recent UI development tasks at work provided a valuable opportunity to revisit CSS-in-JS and utility-first CSS (Tailwind). My day-to-day role rarely involves UI work, so this was a refreshing, if slightly rusty, experience. My aim here is to offer an unbiased comparison of both approaches, focusing on the development workflow and tooling.

Tailwind CSS

Our team's choice of Tailwind was somewhat spontaneous, driven by a desire for efficiency. While familiarity varied, and some skepticism existed, the time savings were a compelling factor.

Positive Aspects

Integration, custom variable creation, and theme development were remarkably straightforward. Extending or building new themes proved intuitive:

<code>@import "tailwindcss";
@theme {  
  --font-script: Comic-sans; // theme extension
  --color-*: initial;  // default overrides
  --color-white: #fff;
  ...
}</code>

The inclusion of base styles, even something as simple as default margin and padding removal, was a significant time saver. This streamlined the workflow considerably.

Tailwind aims for an intuitive experience, which it largely achieves. However, some aspects feel less intuitive. Class naming conventions, while generally clear (e.g., p for padding, mb for margin-bottom), present occasional inconsistencies (e.g., rounded for border-radius). This can be mitigated with custom theme definitions:

<code>@theme { 
  --border-radius: var(--rounded);
  --border-radius-none: var(--rounded-none);
  --border-radius-full: var(--rounded-full);
  // ...etc.
  --rounded*: initial;
}</code>

Overall Impressions

Readability and maintainability were less problematic than anticipated. While the syntax required an adjustment period, and VS Code's IntelliSense lagged occasionally, code remained manageable and easy to navigate, even with multiple classes applied to small elements.

Important Note: Avoid over-reliance on @apply. This can lead to the undesirable outcome of "Tailwind-in-CSS."

Server-Side Rendering (SSR)

Crucially, Tailwind presented no SSR issues during testing. Its seamless integration was a significant advantage.

CSS-in-JS (Emotion)

In 2024-2025, CSS-in-JS solutions are experiencing a decline in popularity, largely due to the rise of server components in frameworks like React.

See: https://www.php.cn/link/9cb4d40fce0492278209290ee3e4ae31

Key Challenges

The major issue stems from the reliance on React's Context API. Mixing server and client components in a React application can lead to data loss and prevent correct style updates on re-renders. This limitation is inherent to many CSS-in-JS libraries.

While compatible alternatives exist, the underlying problem remains. Joshua Comeau's blog provides excellent context on this issue.

Retrospective

In hindsight, the shift to CSS-in-JS felt less beneficial than initially anticipated. While the contained development experience (everything within one file) was initially appealing, this advantage proved less significant over time.

Long-Term Considerations

CSS-in-JS resulted in increased typing and configuration overhead. Compared to Tailwind, it felt less efficient. While conditional prop passing offers power and flexibility:

<code>@import "tailwindcss";
@theme {  
  --font-script: Comic-sans; // theme extension
  --color-*: initial;  // default overrides
  --color-white: #fff;
  ...
}</code>

This can also complicate code understanding and refactoring. Excessive style overwriting signals potential design system inconsistencies:

<code>@theme { 
  --border-radius: var(--rounded);
  --border-radius-none: var(--rounded-none);
  --border-radius-full: var(--rounded-full);
  // ...etc.
  --rounded*: initial;
}</code>

For new projects, I would likely avoid CSS-in-JS.

CSS Variables and Theming

CSS variables are invaluable. Defining a palette once and reusing it across components simplifies styling, offering a similar experience to using predefined component variants.

<code>const Button = styled.button`
  background: ${props => props.variant === 'primary' ? "#ddd" : "#fff"};
`;

render(
  <div>
    <button variant="primary">Primary</button>
  </div>
);</code>

Postprocessors and Configuration

Postprocessors (e.g., PostCSS) are essential for optimizing CSS. They offer significant benefits:

• cssnano: Removes unused code.
• postcss-nested: Enables nested CSS similar to Sass.
• stylelint: Provides linting capabilities.
• autoprefixer: Adds vendor prefixes (though less critical now).
• postcss-import: Enables @import statements.

(Full list: https://www.php.cn/link/2d280461b029134123f1f1a356e176b1)

While adding overhead, postprocessors improve developer experience and CSS performance. The benefits often outweigh the initial investment.

Lightning CSS

Lightning CSS (a Rust-based alternative to PostCSS) offers faster build times and many of the same features. It's worth exploring if you seek a well-integrated solution.

Summary

The CSS landscape is evolving rapidly, with new tools and approaches constantly emerging. My experiences with Tailwind and CSS-in-JS were informative, highlighting both their strengths and weaknesses. The impact of RSC on future CSS tooling is significant and warrants further consideration.

The above is the detailed content of Thoughts on CSS-in-JS and Utility-First CSS (Tailwind). For more information, please follow other related articles on the PHP Chinese website!