CSS frameworks you've worked with

CSS frameworks provide pre-built styles, components, and layout systems so you don't write everything from scratch. The major categories are: utility-first frameworks (Tailwind CSS) that give you low-level utility classes to compose designs, component frameworks (Bootstrap, Material UI) that provide pre-styled components, and CSS-in-JS solutions (styled-components, Emotion) that colocate styles with components. The right choice depends on your project's needs — team size, design system requirements, bundle size constraints, and how much customization you need.

Tailwind CSS provides low-level utility classes (flex, p-4, text-lg, bg-blue-500) that you compose directly in HTML/JSX. Instead of writing custom CSS, you apply small, single-purpose classes. It produces tiny production bundles (only includes classes you actually use), enforces design consistency through a configurable theme, and eliminates the naming problem (no more inventing class names). The tradeoff is verbose markup and a learning curve for the class names.

// Tailwind CSS — utility classes composed in markup
function Card({ title, description }: { title: string; description: string }) {
  return (
    <div className="rounded-lg border bg-card p-6 shadow-sm hover:shadow-md transition-shadow">
      <h3 className="text-lg font-semibold text-foreground">{title}</h3>
      <p className="mt-2 text-sm text-muted-foreground">{description}</p>
    </div>
  );
}

// Strengths:
// ✅ Tiny production bundle (purges unused classes)
// ✅ No context switching between CSS and component files
// ✅ Design system enforced through theme config
// ✅ Responsive design built-in (sm:, md:, lg: prefixes)
// ✅ Dark mode support (dark: prefix)

// Tradeoffs:
// ⚠️ Verbose class strings in markup
// ⚠️ Learning curve for class names
// ⚠️ Harder to extract reusable style patterns without @apply or components

Component frameworks give you pre-built, pre-styled components (buttons, modals, navbars, forms) that you drop into your app. Bootstrap is the classic CSS framework with its own grid system and component library. Material UI (MUI) implements Google's Material Design for React. These are fastest for prototyping and internal tools where custom design isn't critical — but they're harder to customize deeply and can result in 'every site looks the same' syndrome.

CSS-in-JS libraries let you write CSS directly in your JavaScript/TypeScript files, scoped to individual components. They excel at dynamic styles (styles that depend on props or state), theming, and eliminating class name conflicts. The tradeoff is runtime performance overhead (styles are generated at runtime) and larger bundle sizes. The trend in 2024+ is moving away from runtime CSS-in-JS toward zero-runtime alternatives (Tailwind, CSS Modules, vanilla-extract).

// styled-components — CSS-in-JS with tagged template literals
import styled from 'styled-components';

const Card = styled.div<{ elevated?: boolean }>`
  border-radius: 8px;
  padding: 1.5rem;
  background: ${({ theme }) => theme.colors.surface};
  box-shadow: ${({ elevated }) =>
    elevated ? '0 4px 12px rgba(0,0,0,0.1)' : '0 1px 3px rgba(0,0,0,0.05)'};
  transition: box-shadow 0.2s;

  &:hover {
    box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
  }
`;

// Usage
<Card elevated>Content here</Card>

// Strengths:
// ✅ Dynamic styles based on props/state
// ✅ Automatic scoping — no class name conflicts
// ✅ Theming built-in
// ✅ Full CSS power (pseudo-elements, media queries, animations)

// Tradeoffs:
// ⚠️ Runtime overhead (generates CSS at render time)
// ⚠️ Larger bundle size
// ⚠️ Doesn't work with React Server Components (no client JS)
// ⚠️ Industry trend moving toward zero-runtime solutions

This is an experience question — interviewers want to hear about your actual experience, not a textbook comparison. Talk about what you've used, why you chose it for that project, what problems you encountered, and what you'd choose differently next time. Show that you understand the tradeoffs and can make informed decisions based on project requirements.

This question assesses your practical experience with CSS tooling and your ability to evaluate tradeoffs. Interviewers want to see that you've used multiple approaches (not just one), can articulate why you'd choose one over another for a given project, understand the tradeoffs (bundle size, customization, DX, performance), know current industry trends (utility-first gaining, runtime CSS-in-JS declining), and can adapt to whatever the team uses. It's less about knowing every framework and more about demonstrating thoughtful tool selection.