CSS Modules and Component-Based Styling

The Evolution to Component-Based Web Development

Modern web development has shifted dramatically toward component-based architectures. Instead of building pages as monolithic entities, we now construct interfaces from reusable, self-contained components. This shift has been driven by frameworks like React, Vue, and Angular, but has implications for how we approach CSS as well.

graph TD A[Web Development Approaches] --> B[Traditional Page-Based] A --> C[Modern Component-Based] B --> D[Entire Pages] B --> E[Global CSS] B --> F[Tightly Coupled] C --> G[Reusable Components] C --> H[Component-Scoped Styles] C --> I[Loosely Coupled] style C fill:#e8f5e9,stroke:#4CAF50 style G fill:#e8f5e9,stroke:#4CAF50 style H fill:#e8f5e9,stroke:#4CAF50 style I fill:#e8f5e9,stroke:#4CAF50

Traditional CSS approaches face several challenges in component-based architectures:

Global scope: CSS selectors apply globally by default, making it difficult to isolate styles to specific components
Naming collisions: As teams and projects grow, the risk of duplicate class names increases
Style leaking: Styles intended for one component may accidentally affect others
Specificity wars: Developers often resort to increasingly specific selectors to override styles
Maintainability issues: It becomes hard to determine if a style is still needed or what it affects

Component-based styling approaches address these challenges by creating stronger boundaries between components and their styles. This is similar to how object-oriented programming uses encapsulation to hide implementation details and prevent unintended interactions between objects.

What are CSS Modules?

Core Concept

CSS Modules is a CSS file in which all class names and animation names are scoped locally by default. It's not a official specification, but rather a process (typically implemented in a build system like webpack) that transforms CSS classes into unique identifiers to avoid naming collisions.

Think of CSS Modules like namespaces in programming languages - they allow you to use simple, readable class names without worrying about conflicts with other parts of your application.

How CSS Modules Work

When you write a CSS Module, each class is transformed into a unique identifier at build time:

/* Button.module.css */
.button {
  background-color: blue;
  color: white;
  padding: 10px 20px;
  border-radius: 4px;
}

.primary {
  background-color: purple;
}

/* Becomes something like: */
.Button_button_1a2b3c {
  background-color: blue;
  color: white;
  padding: 10px 20px;
  border-radius: 4px;
}

.Button_primary_4d5e6f {
  background-color: purple;
}

In your JavaScript component, you import these transformed class names:

// Button.jsx (React example)
import styles from './Button.module.css';

function Button({ primary, children }) {
  const buttonClass = primary 
    ? `${styles.button} ${styles.primary}` 
    : styles.button;
    
  return (
    <button className={buttonClass}>
      {children}
    </button>
  );
}

When this renders to the DOM, the button element will have classes like Button_button_1a2b3c Button_primary_4d5e6f rather than the original button primary classes. This ensures that these styles don't conflict with any other .button or .primary classes in your application.

Key Benefits of CSS Modules

Local Scope: Styles are automatically scoped to the component
Reusability: Components with their styles can be easily shared and reused
Maintainability: Clear relationship between components and their styles
Composition: Classes can be composed together in a explicit way
Predictability: No unexpected style overrides from other parts of the application

This is similar to how modern package managers in programming help avoid dependency conflicts by creating isolated environments for each package.

CSS Modules in Practice

Setting Up CSS Modules

CSS Modules typically require a build step with a tool like webpack, Vite, or a framework that supports them out of the box:

With webpack

// webpack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.module\.css$/,
        use: [
          'style-loader',
          {
            loader: 'css-loader',
            options: {
              modules: true,
            },
          },
        ],
      },
    ],
  },
};

With Create React App, Next.js, or Vite

These frameworks support CSS Modules out of the box - just name your file with the pattern [name].module.css.

Basic Usage Patterns

1. Component-Specific Styles

/* Card.module.css */
.card {
  border: 1px solid #ddd;
  border-radius: 8px;
  padding: 16px;
  margin-bottom: 16px;
}

.title {
  font-size: 1.2rem;
  margin-top: 0;
  margin-bottom: 8px;
}

.content {
  color: #333;
}

// Card.jsx
import styles from './Card.module.css';

function Card({ title, children }) {
  return (
    <div className={styles.card}>
      <h2 className={styles.title}>{title}</h2>
      <div className={styles.content}>{children}</div>
    </div>
  );
}

2. Composing Classes

/* Button.module.css */
.base {
  padding: 8px 16px;
  border: none;
  border-radius: 4px;
  cursor: pointer;
  font-size: 1rem;
}

.primary {
  background-color: #3498db;
  color: white;
}

.secondary {
  background-color: #f1f1f1;
  color: #333;
  border: 1px solid #ddd;
}

.large {
  padding: 12px 24px;
  font-size: 1.2rem;
}

// Button.jsx
import styles from './Button.module.css';

function Button({ variant = 'primary', size, children }) {
  const buttonClasses = [
    styles.base,
    variant === 'primary' ? styles.primary : styles.secondary,
    size === 'large' ? styles.large : ''
  ].filter(Boolean).join(' ');
  
  return (
    <button className={buttonClasses}>
      {children}
    </button>
  );
}

3. Handling Dynamic Classes

/* Form.module.css */
.formGroup {
  margin-bottom: 16px;
}

.input {
  width: 100%;
  padding: 8px;
  border: 1px solid #ddd;
  border-radius: 4px;
}

.inputError {
  border-color: #e74c3c;
}

.errorMessage {
  color: #e74c3c;
  font-size: 0.875rem;
  margin-top: 4px;
}

// FormGroup.jsx
import styles from './Form.module.css';

function FormGroup({ label, name, value, error, onChange }) {
  const inputClasses = [
    styles.input,
    error ? styles.inputError : ''
  ].filter(Boolean).join(' ');
  
  return (
    <div className={styles.formGroup}>
      <label htmlFor={name}>{label}</label>
      <input
        id={name}
        name={name}
        value={value}
        onChange={onChange}
        className={inputClasses}
      />
      {error && <div className={styles.errorMessage}>{error}</div>}
    </div>
  );
}

Advanced CSS Modules Features

Composition

CSS Modules allows you to compose class names from other classes:

/* typography.module.css */
.heading {
  font-family: 'Montserrat', sans-serif;
  font-weight: 700;
  line-height: 1.2;
}

.largeHeading {
  composes: heading;
  font-size: 2rem;
}

.mediumHeading {
  composes: heading;
  font-size: 1.5rem;
}

You can also compose from other files:

/* Button.module.css */
.button {
  /* Button styles */
}

/* Card.module.css */
.actionButton {
  composes: button from './Button.module.css';
  margin-top: 12px;
}

This is similar to inheritance in programming languages, allowing you to build complex styles from simpler building blocks.

Global Exceptions

Sometimes you need a global class (like for third-party libraries). You can mark a class as global using :global:

/* Component.module.css */
.component {
  /* Local styles */
}

:global(.external-library-class) {
  /* Global styles that won't be transformed */
}

Conversely, within a global CSS file, you can create a local scope with :local:

/* global.css */
.global-style {
  /* Global styles */
}

:local(.scoped-style) {
  /* This will be scoped like a CSS Module */
}

Values in CSS Modules

Some implementations of CSS Modules (like using PostCSS) allow you to export values from your CSS:

/* colors.module.css */
@value primary: #3498db;
@value secondary: #2ecc71;
@value textDark: #333333;

.button {
  background-color: primary;
  color: white;
}

// Component.jsx
import { primary, secondary } from './colors.module.css';

console.log('Primary color:', primary); // "#3498db"

This creates a tighter integration between your CSS and JavaScript, similar to how design tokens work in design systems.

CSS-in-JS: An Alternative Approach

CSS-in-JS is another popular approach to component-based styling. Instead of writing CSS in separate files, styles are written directly in JavaScript.

Common CSS-in-JS Libraries

Styled Components: Creates React components with attached styles
Emotion: Versatile CSS-in-JS library with multiple APIs
JSS: Low-level CSS-in-JS library
Stitches: Performance-focused CSS-in-JS with near-zero runtime

Basic Styled Components Example

// Button.jsx with Styled Components
import styled from 'styled-components';

const Button = styled.button`
  background-color: ${props => props.primary ? '#3498db' : 'transparent'};
  color: ${props => props.primary ? 'white' : '#3498db'};
  border: ${props => props.primary ? 'none' : '1px solid #3498db'};
  padding: 8px 16px;
  border-radius: 4px;
  font-size: ${props => props.large ? '1.2rem' : '1rem'};
  cursor: pointer;
  
  &:hover {
    background-color: ${props => props.primary ? '#2980b9' : 'rgba(52, 152, 219, 0.1)'};
  }
`;

export default Button;

// Usage in another component
import Button from './Button';

function App() {
  return (
    <div>
      <Button primary>Primary Button</Button>
      <Button>Secondary Button</Button>
      <Button primary large>Large Primary Button</Button>
    </div>
  );
}

Pros and Cons of CSS-in-JS vs CSS Modules

Feature	CSS Modules	CSS-in-JS
Scoped Styles	✅ (at build time)	✅ (at runtime)
Performance	✅ No runtime overhead	⚠️ Some runtime overhead (varies by library)
Dynamic Styling	⚠️ Limited (requires inline styles or class switching)	✅ Full JavaScript power for dynamic styles
Developer Experience	✅ Standard CSS syntax	⚠️ Template literals or JS objects (IDE support varies)
Build Requirements	✅ Requires build setup	✅ Requires build setup
Server-Side Rendering	✅ Simple	⚠️ Requires additional setup

The choice between CSS Modules and CSS-in-JS often comes down to team preferences, performance requirements, and the specific needs of your project. Many development teams use both approaches for different scenarios.

Utility-First CSS: The Tailwind Approach

Utility-first CSS is another approach to component-based styling that has gained significant popularity, particularly with the rise of Tailwind CSS. Instead of writing custom CSS for components, you compose styles using small, single-purpose utility classes directly in your HTML.

The Core Concept

Utility-first CSS provides a large set of utility classes that each do one specific thing, like setting a particular padding, margin, color, or flex property. Instead of creating custom component classes, you apply these utilities directly to elements.

Tailwind CSS Example

<!-- Traditional approach -->
<button class="btn btn-primary"></button>

<!-- Utility-first approach with Tailwind -->
<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
  Button
</button>

With React or other component frameworks, you can still compose these utilities into reusable components:

// Button.jsx with Tailwind
function Button({ primary, children }) {
  const baseClasses = "font-bold py-2 px-4 rounded";
  const variantClasses = primary 
    ? "bg-blue-500 hover:bg-blue-700 text-white" 
    : "bg-transparent hover:bg-blue-500 text-blue-700 hover:text-white border border-blue-500 hover:border-transparent";
    
  return (
    <button className={`${baseClasses} ${variantClasses}`}>
      {children}
    </button>
  );
}

Addressing Common Concerns

1. "But the HTML gets so cluttered!"

This is a common initial reaction. However, when using component frameworks, the class lists are typically encapsulated within component definitions, so the actual application code remains clean. It's similar to how functional programming might favor composition of small, focused functions over larger multi-purpose ones.

2. "What about reusability?"

Reusability is achieved at the component level rather than the CSS level. Instead of creating reusable CSS classes, you create reusable components that encapsulate common utility combinations. Most frameworks that use Tailwind provide ways to extract common patterns, such as:

// Extracted component
function Card({ title, children }) {
  return (
    <div className="bg-white rounded-lg shadow-md p-6 mb-4">
      <h2 className="text-xl font-bold mb-2">{title}</h2>
      <div>{children}</div>
    </div>
  );
}

3. "Is it maintainable at scale?"

Many large companies have successfully adopted utility-first CSS for major applications. The component-based approach, combined with defined patterns and style guides, can make maintenance easier because:

Changes are localized to components, reducing unintended side effects
Visual patterns are explicitly visible in the markup
Less context switching between files to understand styling

Benefits of Utility-First CSS

Reduced CSS growth: Your CSS file size doesn't increase as your project grows
No naming challenges: You don't have to come up with meaningful class names for everything
Fast iteration: Make changes without touching CSS files or build processes
Consistency: Built-in design constraints from the predefined utility system
Mobile-first: Built-in responsive utilities (e.g., md:flex for medium screens)

Many teams find that utility-first CSS shines for rapid UI development and design system implementation. It's particularly well-suited for teams that want to reduce CSS maintenance overhead and standardize their design language.

Atomic CSS and CSS Utility Libraries

Tailwind isn't the only utility-based approach to CSS. Several other libraries and methodologies focus on atomic, utility-based styling.

What is Atomic CSS?

Atomic CSS is a CSS architecture approach where styles are broken down into their smallest, indivisible parts (atoms). Each class does only one specific thing, and these atomic classes are combined to create the desired styling.

Popular Atomic/Utility CSS Libraries

1. Tachyons

One of the original utility CSS frameworks, focused on readable class names and responsive design:

<div class="flex items-center justify-between ph3 pv2 bg-black-90 white">
  <h1 class="f5 f4-ns dib mr3">Site Name</h1>
  <div>
    <a class="link dib white mr3" href="#">Home</a>
    <a class="link dib white mr3" href="#">About</a>
    <a class="link dib white" href="#">Contact</a>
  </div>
</div>

2. Atomic CSS (ACSS)

Created by Yahoo, this approach uses attribute syntax for flexibility:

<div class="Bd Bdc(#ccc) P(10px) M(20px)">
  This div has a border, padding, and margin.
</div>

3. Tailwind CSS

The most popular utility CSS framework today, with a comprehensive set of utilities:

<div class="border border-gray-300 p-4 m-6">
  This div has a border, padding, and margin.
</div>

4. Windi CSS / UnoCSS

Newer alternatives to Tailwind with on-demand generation and faster build times:

<div class="border-gray-300 p4 m6">
  This div has a border, padding, and margin.
</div>

Creating Your Own Utility System

Some teams create custom utility systems tailored to their specific needs. This can be done using CSS custom properties:

:root {
  --space-1: 0.25rem;
  --space-2: 0.5rem;
  --space-3: 1rem;
  --space-4: 2rem;
  
  --color-primary: #3498db;
  --color-secondary: #2ecc71;
  --color-gray-100: #f8f9fa;
  --color-gray-200: #e9ecef;
  /* ... */
}

/* Spacing utilities */
.m-1 { margin: var(--space-1); }
.m-2 { margin: var(--space-2); }
.m-3 { margin: var(--space-3); }
.m-4 { margin: var(--space-4); }

.p-1 { padding: var(--space-1); }
.p-2 { padding: var(--space-2); }
.p-3 { padding: var(--space-3); }
.p-4 { padding: var(--space-4); }

/* Color utilities */
.bg-primary { background-color: var(--color-primary); }
.bg-secondary { background-color: var(--color-secondary); }
.bg-gray-100 { background-color: var(--color-gray-100); }
.bg-gray-200 { background-color: var(--color-gray-200); }

/* ... */

This combines the benefits of design tokens (using CSS variables) with the utility-first approach, giving you complete control over your utility system.

Combining Multiple Approaches

In real-world projects, it's common to use a combination of these approaches rather than strictly adhering to just one.

Hybrid Approaches in Practice

1. CSS Modules with Utility Classes

Use CSS Modules for component-specific styles, but include some utility classes for common adjustments:

/* global-utilities.css */
.mt-4 { margin-top: 1rem; }
.mb-4 { margin-bottom: 1rem; }
.text-center { text-align: center; }
/* ... */

/* Button.module.css */
.button {
  padding: 8px 16px;
  border-radius: 4px;
  font-weight: bold;
}

.primary {
  background-color: #3498db;
  color: white;
}

// Component.jsx
import styles from './Button.module.css';
import './global-utilities.css';

function Component() {
  return (
    <div>
      <button className={`${styles.button} ${styles.primary} mt-4`}>
        Submit
      </button>
    </div>
  );
}

2. Tailwind with Component Extraction

Use Tailwind for most styling, but extract commonly used patterns into components or apply classes:

// Button.jsx
function Button({ variant = 'primary', size = 'md', children }) {
  const baseClasses = "font-bold rounded focus:outline-none focus:ring-2";
  
  const sizeClasses = {
    sm: "py-1 px-2 text-sm",
    md: "py-2 px-4 text-base",
    lg: "py-3 px-6 text-lg"
  };
  
  const variantClasses = {
    primary: "bg-blue-500 hover:bg-blue-700 text-white focus:ring-blue-300",
    secondary: "bg-gray-200 hover:bg-gray-300 text-gray-800 focus:ring-gray-300",
    danger: "bg-red-500 hover:bg-red-700 text-white focus:ring-red-300"
  };
  
  return (
    <button className={`${baseClasses} ${sizeClasses[size]} ${variantClasses[variant]}`}>
      {children}
    </button>
  );
}

3. CSS-in-JS with Design Tokens

Use CSS-in-JS for component styles but maintain a design token system for consistency:

// tokens.js
export const tokens = {
  colors: {
    primary: '#3498db',
    secondary: '#2ecc71',
    text: {
      dark: '#333333',
      light: '#ffffff'
    }
  },
  spacing: {
    xs: '0.25rem',
    sm: '0.5rem',
    md: '1rem',
    lg: '1.5rem',
    xl: '2rem'
  },
  // ...
};

// Button.jsx with styled-components
import styled from 'styled-components';
import { tokens } from './tokens';

const Button = styled.button`
  background-color: ${props => props.variant === 'primary' ? tokens.colors.primary : 'transparent'};
  color: ${props => props.variant === 'primary' ? tokens.colors.text.light : tokens.colors.primary};
  padding: ${tokens.spacing.sm} ${tokens.spacing.md};
  border-radius: 4px;
  border: ${props => props.variant === 'primary' ? 'none' : `1px solid ${tokens.colors.primary}`};
  font-weight: bold;
`;

export default Button;

Practical Guidelines for Choosing Approaches

When deciding on styling approaches for your project, consider these factors:

Team experience and preferences: Use what your team is comfortable with and productive in
Project scale and complexity: Larger projects may benefit more from strict component encapsulation
Performance requirements: Consider build and runtime performance impacts
Design system integration: Choose approaches that work well with your design system
Legacy code considerations: Consider how to integrate with existing codebases

The most successful styling strategies are those that are actually followed by the team. A simple approach that everyone uses is better than a sophisticated one that's applied inconsistently.

Component-Based Styling Architecture

Beyond the specific technologies, component-based styling requires thinking about how to architect your styles to support a component-based UI.

Design Tokens as the Foundation

Start with a centralized design token system that defines your design language:

// In a CSS file
:root {
  --color-primary: #3498db;
  --color-secondary: #2ecc71;
  --spacing-unit: 8px;
  /* ... */
}

// Or in JavaScript
export const tokens = {
  colors: {
    primary: '#3498db',
    secondary: '#2ecc71'
  },
  spacing: {
    unit: 8
  }
  // ...
};

Component Style Hierarchy

graph TD A[Design Tokens] --> B[Global Styles] A --> C[Layout Components] A --> D[UI Components] B --> E[Reset/Normalize] B --> F[Typography] B --> G[Utilities] C --> H[Container] C --> I[Grid] C --> J[Flex] D --> K[Button] D --> L[Card] D --> M[Modal] K --> N[Component Variants] L --> O[Component Variants] M --> P[Component Variants]

1. Global Styles

Minimal global styles for consistent defaults:

CSS resets or normalization
Base typography
Globally available utility classes (optional)

2. Layout Components

Components focused on structure and positioning:

Container
Grid
Section
Stack (vertical spacing)
Cluster (horizontal grouping)

3. UI Components

Presentational components that make up your interface:

Buttons
Cards
Forms and inputs
Navigation elements
Dialogs and modals

4. Composed Components

Higher-level components composed of multiple UI components:

SearchForm (composed of inputs, buttons)
ProductCard (composed of card, button, image)
NavigationBar (composed of container, buttons, links)

Styling Conventions for Component Libraries

1. Component API Consistency

Ensure consistent prop/attribute patterns across components:

Consistent naming (size vs variant vs color)
Consistent values (e.g., sizes as 'sm', 'md', 'lg' across all components)
Consistent behavior for common functionality

2. Style Composition Patterns

Define how styles combine and override:

Base styles + variant styles
Style precedence rules
Handling of custom user styles

3. Documentation

Include for each component:

Available variants/props/modifiers
Examples of usage
Design guidelines
Accessibility considerations

A well-structured component styling architecture creates a clear, predictable system that designers and developers can easily understand and work with.

Performance Considerations

Different styling approaches can have significant performance implications for your application.

CSS Performance Metrics

1. Build-Time Metrics

Build Speed: How quickly styles can be processed during build
Output Size: Size of the generated CSS
Dead Code Elimination: Ability to remove unused styles

2. Runtime Metrics

Initial Load Time: Time to download, parse, and apply styles
Runtime Overhead: JavaScript processing needed for styling
Rendering Performance: Impact on frame rates during animations
Memory Usage: Memory footprint of the styling approach

Performance Comparison

Approach	Build-Time Performance	Runtime Performance	Bundle Size Impact
Traditional CSS	✅ Fast (simple processing)	✅ Excellent (native browser processing)	⚠️ Large (can include unused CSS)
CSS Modules	⚠️ Medium (requires transformation)	✅ Excellent (compiled to static CSS)	✅ Small (includes only used styles)
CSS-in-JS (Runtime)	⚠️ Medium (additional processing)	⚠️ Medium (runtime style generation)	⚠️ Medium (includes JS libraries)
CSS-in-JS (Static)	❌ Slower (complex extraction)	✅ Excellent (pre-generated CSS)	✅ Small (optimized output)
Utility-First CSS	⚠️ Medium (initial generation)	✅ Excellent (static CSS)	✅ Small (with proper purging)

Performance Optimization Techniques

1. CSS Optimization

Code Splitting: Load only the CSS needed for the current page

// In a component-based framework
import styles from './ComponentStyles.css'; // Only loads when component is used

Tree Shaking / Purging: Remove unused CSS

// postcss.config.js with PurgeCSS
module.exports = {
  plugins: [
    require('postcss-import'),
    require('tailwindcss'),
    require('autoprefixer'),
    process.env.NODE_ENV === 'production'
      ? require('@fullhuman/postcss-purgecss')({
          content: ['./src/**/*.html', './src/**/*.js'],
          defaultExtractor: content => content.match(/[A-Za-z0-9-_:/]+/g) || []
        })
      : false
  ].filter(Boolean)
};

Critical CSS Extraction: Inline critical styles for faster initial rendering

// Using a tool like critical
const critical = require('critical');

critical.generate({
  base: 'dist/',
  src: 'index.html',
  target: 'index-critical.html',
  inline: true,
  width: 1300,
  height: 900
});

2. CSS-in-JS Optimization

Static Extraction: Pre-generate CSS at build time instead of runtime

// Using styled-components with Babel plugin
// babel.config.js
module.exports = {
  plugins: [
    ['babel-plugin-styled-components', {
      displayName: true,
      ssr: true,
      pure: true
    }]
  ]
};

Server-Side Rendering: Generate styles on the server to avoid client-side flash

Memoization: Cache styled components to avoid regeneration

// Memoized styled component
import React, { useMemo } from 'react';
import styled from 'styled-components';

function DynamicButton({ color, children }) {
  const StyledButton = useMemo(() => {
    return styled.button`
      background-color: ${color};
      color: white;
      padding: 8px 16px;
      border-radius: 4px;
    `;
  }, [color]);
  
  return <StyledButton>{children}</StyledButton>;
}

3. General Best Practices

Prefer composing small components over large, complex ones
Avoid excessive dynamic styling that changes on every render
Use production builds of styling libraries which often include optimizations
Measure before optimizing - identify actual bottlenecks in your application

Performance optimization should be approached holistically, considering both initial load performance and ongoing interaction performance.

Practice Activity: Component-Based Styling

Activity Instructions:

Choose a component-based styling approach (CSS Modules, CSS-in-JS, or utility-first CSS)
Create a simple component library with at least three components:
- Button (with multiple variants)
- Card (with header, content, and footer sections)
- Form input (with label and validation state)
Implement the components using your chosen approach
Create a simple page that uses all of your components
Add a feature that demonstrates the dynamic capabilities of your approach (e.g., theme switching)

Approach 1: CSS Modules Example

/* Button.module.css */
.button {
  padding: 8px 16px;
  border-radius: 4px;
  font-weight: bold;
  cursor: pointer;
  transition: background-color 0.2s;
  border: none;
}

.primary {
  background-color: var(--color-primary, #3498db);
  color: white;
}

.primary:hover {
  background-color: var(--color-primary-dark, #2980b9);
}

.secondary {
  background-color: transparent;
  border: 1px solid var(--color-primary, #3498db);
  color: var(--color-primary, #3498db);
}

.secondary:hover {
  background-color: rgba(52, 152, 219, 0.1);
}

.large {
  padding: 12px 24px;
  font-size: 1.1rem;
}

.small {
  padding: 4px 12px;
  font-size: 0.9rem;
}

// Button.jsx
import React from 'react';
import styles from './Button.module.css';

function Button({ 
  variant = 'primary', 
  size, 
  children, 
  ...props 
}) {
  const buttonClasses = [
    styles.button,
    styles[variant],
    size && styles[size]
  ].filter(Boolean).join(' ');
  
  return (
    <button className={buttonClasses} {...props}>
      {children}
    </button>
  );
}

export default Button;

Approach 2: Styled Components Example

// Button.js
import styled, { css } from 'styled-components';

const sizeStyles = {
  small: css`
    padding: 4px 12px;
    font-size: 0.9rem;
  `,
  large: css`
    padding: 12px 24px;
    font-size: 1.1rem;
  `
};

const Button = styled.button`
  padding: 8px 16px;
  border-radius: 4px;
  font-weight: bold;
  cursor: pointer;
  transition: background-color 0.2s;
  
  /* Base styles */
  ${props => props.variant === 'primary' && css`
    background-color: ${props => props.theme.colors.primary};
    color: white;
    border: none;
    
    &:hover {
      background-color: ${props => props.theme.colors.primaryDark};
    }
  `}
  
  ${props => props.variant === 'secondary' && css`
    background-color: transparent;
    color: ${props => props.theme.colors.primary};
    border: 1px solid ${props => props.theme.colors.primary};
    
    &:hover {
      background-color: rgba(52, 152, 219, 0.1);
    }
  `}
  
  /* Size styles */
  ${props => props.size && sizeStyles[props.size]}
`;

export default Button;

Approach 3: Tailwind CSS Example

// Button.jsx
import React from 'react';

function Button({ 
  variant = 'primary', 
  size = 'md', 
  children, 
  ...props 
}) {
  // Base classes for all buttons
  const baseClasses = "font-bold rounded focus:outline-none focus:ring-2 transition";
  
  // Size-specific classes
  const sizeClasses = {
    sm: "py-1 px-3 text-sm",
    md: "py-2 px-4 text-base",
    lg: "py-3 px-6 text-lg"
  };
  
  // Variant-specific classes
  const variantClasses = {
    primary: "bg-blue-500 hover:bg-blue-600 text-white focus:ring-blue-300",
    secondary: "border border-blue-500 text-blue-500 hover:bg-blue-50 focus:ring-blue-200"
  };
  
  // Combine all classes
  const buttonClasses = `${baseClasses} ${sizeClasses[size]} ${variantClasses[variant]}`;
  
  return (
    <button className={buttonClasses} {...props}>
      {children}
    </button>
  );
}

export default Button;

Extension Challenge:

Try implementing the same component using all three approaches (CSS Modules, CSS-in-JS, and utility-first CSS). Compare the developer experience, code readability, and any performance differences. Which approach felt most natural to you? Which would you prefer for larger projects?

Conclusion

Component-based styling approaches have evolved to address the challenges of modern web development, providing better encapsulation, reusability, and maintainability. Each approach—CSS Modules, CSS-in-JS, and utility-first CSS—offers unique benefits and tradeoffs:

CSS Modules provide scoped CSS with minimal runtime overhead, making them a solid choice for performance-critical applications
CSS-in-JS offers the most dynamic styling capabilities and tightest integration with component logic
Utility-first CSS provides rapid development and consistency through predefined design constraints

Many successful projects use hybrid approaches, combining aspects of different methodologies to meet their specific needs. The most important factor is establishing a consistent system that your team can effectively use.

As frontend development continues to evolve, these component-based styling approaches will likely grow and adapt. Stay informed about new tools and techniques, but remember that the fundamental principles of good CSS organization—modularity, reusability, and maintainability—remain constant regardless of the specific technology you choose.

In this module, we've covered CSS organization methodologies, CSS variables, and component-based styling approaches. Together, these tools and techniques provide a solid foundation for building modern, maintainable CSS architectures that can grow with your projects.