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? |