Choosing the technology stack

The design-system stack shapes development speed, maintenance cost, onboarding friction, and how easily components get adopted in products. There is no “correct forever” stack — there is a stack that matches team skills, product type, and support horizon.

Selection criteria

1. Team: what they already know, whether experts exist, how steep a learning curve is acceptable.
2. Products: web-only or multi-platform, browser and performance requirements.
3. Ecosystem: community, libraries, hiring, technology longevity.
4. Time-to-market: how much time you have to bootstrap the DS.

Do not pick a technology only because it is “trendy.” Pick one the team can actually maintain for a year or more.

Frontend: React and alternatives

React

The most common base for modern design systems: Material UI, Ant Design, Chakra, shadcn/ui. Pros — ecosystem, TypeScript, flexibility, many examples. Cons — many ways to do the same thing; you need discipline in component APIs.

Vue / Angular / Svelte

Vue works well for teams that value simpler syntax. Angular fits enterprise with stricter structure. Svelte offers a great runtime and bundle size, but a smaller DS ecosystem.

Web Components

A strong option when consumers use multiple frameworks. Cons: harder DX, fewer familiar patterns, more care needed for accessibility and API shape.

Styling approaches

Tailwind CSS (utility-first)

Fast development, good spacing/color discipline when tokens are configured, small final CSS after purge. Cons — verbose markup and a learning curve for utility classes.

CSS Modules / Sass

Familiar CSS, scoping, no runtime cost. Weaker for dynamic themes unless you plan CSS variables carefully.

CSS-in-JS (styled-components, emotion)

Convenient for dynamic themes and co-located styles. Cons — runtime overhead, harder debugging, heavier bundles without discipline.

For a DS, the winning combo is often tokens (CSS variables / theme object) + one styling approach, not a mix of three approaches in one package.

Documentation and build

Storybook

The industry standard for UI libraries: component isolation, variants, a11y addons, visual regressions, living examples. For this course it is a required part of the stack.

Alternatives like Docz/Docusaurus help with textual site docs, but they are a poor substitute for a component explorer.

Build tools

• Vite — fast DX for apps and demos.
• Rollup / tsup / unbuild — convenient for building a publishable library.
• Webpack — still common in enterprise, but heavier to configure.

For a component library you usually split: Vite/Storybook for development, Rollup/tsup for the npm artifact.

Recommended course stack

React 18+ (TypeScript)
Design Tokens (JS objects → CSS variables)
Tailwind or CSS Modules on top of tokens
Storybook
Vite (dev) + library build for publishing
Vitest + Testing Library (as the system grows)

Why this:

• React transfers well across learning and production cases;
• tokens give a single source of truth independent of the styling layer;
• Storybook makes the system testable and documentable from the first component.

Tradeoffs — honestly

| Choice | Upside | Cost | | :--- | :--- | :--- | | React | Ecosystem, hiring, examples | Need agreement on patterns | | Tailwind | Speed, scale consistency | Verbose JSX, config discipline | | CSS-in-JS | Dynamic themes | Runtime and complexity | | Web Components | Cross-framework | Harder DX and adoption | | Storybook | Living docs and isolation | Setup and story maintenance |

A practical decision for your team

Before the final choice, answer in writing:

1. Which framework is already in production?
2. Do you need themes (light/dark/white-label)?
3. Will the library be a publishable package or an internal monorepo package?
4. Who writes docs — designers, engineers, or both?

The final decision doc should include: framework, styling, docs tool, build, rationale, and rejected alternatives. Without that, the stack gets “re-chosen” every sprint.