I built AliveUI because adding meaningful motion to UIs with Tailwind is a second-class citizen. You reach for Framer Motion, write 40 lines of keyframes, or pile on JS runtime for something that should just be a class.

AliveUI treats depth and motion the way Tailwind treats spacing — as a primitive you compose, not a library you configure.

A few things that make it different:

Depth layers (d1–d3): One class gives an element physically correct elevation — shadow, border, background, and hover lift all update together.

Motion tokens: alive-enter, alive-enter-down, alive-enter-right, alive-enter-left, alive-enter-fade, alive-enter-scale are generated CSS keyframe utilities. Stagger is automatic via --alive-index. Zero JS runtime, works with any HTML.

Data-attribute interactivity: Accordion, modal, drawer, tabs, dropdown — driven by data-alive-* attributes and an optional 2KB runtime.

Arbitrary values: w-[340px], bg-[#ff6b6b] — same bracket syntax as Tailwind for escape hatches.

Setup is a PostCSS plugin, Vite plugin, or standalone CLI. Scans your source files, generates only what you use.

npm install @alivecss/aliveui

Site + live demos: https://aliveui.dev GitHub: https://github.com/pratikshadake/aliveui

Curious what people think : is motion as a CSS primitive the right abstraction, or does it belong in JS?