UI with a point of view

Before writing a single component, I settled the design tokens: a zinc-based palette with light and dark surface ramps, semantic naming (--app-bg, --app-surface, --app-text), and a single blue-600 accent that would carry all interactive states.

Getting tokens right first meant every component I built after was anchored to the same foundation. Refactoring a color meant one change in one place — not hunting down thirty-two hardcoded hex values.

Svelte 5's runes model made component state feel direct — no boilerplate, no wrapping everything in signals. Tailwind 4's Vite plugin made the design system CSS-first: tokens live in CSS, not a config object, which meant the components stayed close to the styling decisions.

The tradeoff: less ecosystem than a React/shadcn approach. No massive open-source community publishing Sprix-compatible blocks. But the APIs stay direct, the bundle stays lean, and the components feel exactly how I want them to feel — not shaped by another library's opinions.

The single biggest design decision: use strong edges instead of elevation shadows to separate surfaces. A card on Sprix has a 1px zinc-200 border and a white background. No shadow-xl.

This keeps the UI calm in both light and dark modes — shadows shift in color across themes, borders don't. It forces hierarchy to come from whitespace, typography weight, and surface contrast instead of depth illusions. The result reads as flat but not blank.

The guiding rule was: each component does one thing well and accepts props that make the common cases easy. No giant polymorphic base classes, no deep inheritance chains. A Button is a Button. A Card is a Card. Compose them at the page level.

A component library that only shows isolated components isn't a design system — it's a parts list. To prove Sprix worked, I assembled four real product screen flows using only Sprix primitives: a checkout flow, an auth screen, an operations dashboard, and a CMS editor.

These screens appear on the Sprix site as the showcase section. They're the real test: do the components compose cleanly under pressure? The answer had to be yes before I called the library done.