DriftKit
Motion-first React components. Spring physics by default.
Project snapshot
Design, UI, Engineering, Strategy
Live
React, Next.js, Framer Motion, Tailwind, TypeScript
A motion-first component library with live previews, copyable code, named recipes, spring presets, an interactive playground, and an in-context product demo.
Teach motion principles through components people can actually use, without making the library feel like homework or hiding behind physics jargon.
A growing library of 52+ copy-paste React components built on Framer Motion and Tailwind. Every interaction is powered by spring physics, with live examples and plain-language controls that help designers understand why motion feels right.
How the system works
Motion baked into the primitive
Buttons, lists, cards, inputs, dialogs, and showpiece interactions all start with spring behavior instead of static UI plus a decorative transition.
Every demo is the real thing
The project page and library both show working components, not screenshots, so the feel of each interaction is part of the documentation.
Controls designers can feel
Mass, stiffness, and damping become visible and tunable, giving designers a way to connect physical language to what happens on screen.
Teaching without blocking shipping
Components are meant to be copied, edited, and learned from in place. The code is the lesson, but the user still leaves with something usable.
A library of small UI pieces — buttons, forms, lists, cards — that move with physics instead of stiff, canned animations. Designers drop them into their products to make interfaces feel alive without hiring a motion specialist.
Each card below is the actual working component — not a screenshot. Move your cursor around. Hit the </> button on any card to see the code.
Interactive cards respond to your cursor. The rest loop on their own.
A fake product using five of these components at once
This isn't a mockup — every piece below is live. It's what a real landing page looks like when you drop DriftKit in.
Ship interfaces that feel alive without hiring a motion specialist. Copy-paste components, tune to taste, move on with your day.
- No install. Copy, paste, ship.
- Zero config — just React and Framer Motion.
- Accessibility baked in. Reduced-motion respected.
- Tokens and named presets instead of raw numbers.
The problem
Most component libraries ship with CSS transitions and easing curves. Motion feels tacked on. Students and junior designers copy animations without understanding why they feel cheap — flat durations, wrong curves, no sense of physics.
The hard part is that motion is easy to notice and hard to name. A button can feel sticky, floaty, cheap, snappy, or alive, but most tools only give you a duration box and a cubic-bezier curve.
The approach
Build a library where motion is the foundation, not the garnish. Every component starts from springs — mass, stiffness, damping. Include a playground that shows the curve while you tune. Show the code next to the component. Copy-paste, no install.
The teaching bet is that people learn motion fastest when they can feel the difference, change one value, and immediately see what changed.
The teaching loop
DriftKit is structured around a loop I kept seeing in class and product work: feel the interaction, name what is happening, tune the constraint, then ship the component in context.
That loop matters because motion taste is not built from memorizing curves. It is built from repeated comparisons between intent and feel.
Start with motion quality
The first question is not duration. It is whether the interaction has weight.
Give the behavior language
Recipes like jelly hover or iris wipe make motion easier to discuss than raw numbers.
Expose useful constraints
Stiffness and damping create a small control surface that still changes the feel.
Make it copyable
The final test is whether someone can use the component without a motion lecture.
What I designed and built
52+ components across two tiers — Showpieces (cursor-driven, physics-forward) and Standard (nav, buttons, inputs, tabs, accordion, dialog, and more). Live code view for each. Playground with mass/stiffness/damping sliders and a rendered spring curve. Multi-format code export. A fake product page demonstrates how the components compose in a real interface. All hosted on Vercel, all open source.
Behind the build
Every component started as a teaching artifact. Before writing the code I kept sketching what students were tripping on: why a button's ease-out looked cheap, why page transitions felt uneasy, what separates expressive motion from decorative motion. The library is those conversations turned into copy-paste components.
The API is a constraint. Every component exposes just two physical controls — stiffness and damping — because "tune a cubic-bezier" is a nightmare and "does it feel good" shouldn't require math. The named recipes ("jelly hover", "iris wipe", "chonk") matter more than the numbers; numbers don't teach, feelings do.
Craft decisions I care about
Every tile in the gallery is the actual component running live, not a static preview — portfolio-as-documentation, documentation-as-portfolio. Spring values are presets with real names ("jelly hover", "iris wipe"), not numbers, because the numbers are meaningless until you feel them. Reduced-motion respected everywhere. Zero dependencies on anything outside React + Framer Motion.