Styling
Scope
This section covers methodologies, frameworks, preprocessors, and libraries used for writing, organizing, and managing CSS styles within our frontend applications. This is distinct from UI component libraries (which use styling methods) but focuses on the underlying styling approach itself.
Overview
ADOPT
Proven technologies we have high confidence in; our default choices.
TRIAL
Promising technologies to explore and evaluate for adoption.
ASSESS
Interesting technologies requiring investigation.
HOLD
Not recommended for new work; plan migration from existing uses.
Technologies Breakdown
Tailwind CSS ADOPT
The primary and recommended approach for styling new applications and components, especially within React/Next.js projects. Leveraged by adopted UI tools like shadcn/ui and Origin-UI.
Enables rapid development of custom UIs via utility classes, promotes consistency through a constrained set of design tokens, avoids naming collisions, and results in highly optimized production CSS. Strong team preference and proven productivity benefits.
CSS Modules ADOPT
Recommended for styling components when Tailwind CSS is not used or when component-specific, scoped styles are preferred over utility classes for certain elements. Often used in conjunction with Sass/SCSS for enhanced capabilities. Supported out-of-the-box by many frameworks (Next.js, Vite).
Provides local scoping for CSS class names by default, preventing naming conflicts between components. Offers a clean separation of styles from component logic while keeping CSS syntax familiar. Integrates well with build tools and preprocessors. Adopted as a reliable method for component-scoped styling.
Sass/SCSS ADOPT
Use as a CSS preprocessor, primarily in conjunction with CSS Modules or for managing global styles/themes. Leverage features like variables (though prefer CSS Custom Properties where possible), mixins, nesting, and functions to enhance CSS authoring.
Extends CSS with powerful features that aid in organization, maintainability, and theming. Widely supported by build tools and frameworks. Our team has experience with it, and it remains valuable for complex styling logic and managing design tokens/themes, especially when not using Tailwind's config-driven approach extensively.
Vanilla CSS + BEM/SMACSS HOLD
Avoid for new projects, even simple ones. Maintain existing usage in legacy codebases as needed, but prioritize migration to CSS Modules or Tailwind CSS during refactoring.
While standard CSS is the foundation, relying solely on manual naming conventions like BEM for scoping and organization is less efficient and more error-prone compared to automated solutions like CSS Modules (local scoping) or the utility-based approach of Tailwind CSS.
CSS-in-JS (Styled Components, Emotion) HOLD
Avoid for new projects. Used in some legacy applications; plan for migration towards Tailwind CSS or CSS Modules where feasible during refactoring or feature work.
While popular and powerful, these libraries can introduce runtime overhead, increase bundle size, and sometimes conflict with newer framework features (like React Server Components) or performance optimization techniques (static extraction challenges). Our adopted approaches (Tailwind, CSS Modules) offer better performance characteristics and align better with current best practices and framework directions.