What if a component library didn't wait for you to have a free weekend? What if it woke up every morning, found something interesting on the internet, and built a new interactive component before you'd finished your coffee?
That's Prism. It's my design engineering component library, and it builds itself every day.
The aesthetic
Every component in Prism shares a visual language I'd describe as "quiet confidence". The background is near-black (#050505). Colours are luminous pastels that shift and respond to your cursor position. Nothing is loud. Nothing demands attention. But everything moves.
Spring physics drive every animation. Not CSS transitions, not cubic beziers; actual spring equations running in requestAnimationFrame. The result is motion that feels physical. A 2-3 pixel overshoot on a hover. A 2-3 degree tilt that settles naturally.
The cursor is the colour source. Move it to the top-left and you get cool blues. Bottom-right brings warm pinks. Every component inherits this, so the whole library feels like one coherent thing.
Deep dive: MagneticButton
MagneticButton was the first component I built by hand. Hover near it and the button drifts toward your cursor, pulled by a spring force. The text inside shifts independently, creating a subtle parallax. A soft glow appears beneath it, tinted by the cursor-reactive colour system.
The implementation is pure React and requestAnimationFrame. No animation libraries. What makes it interesting isn't any single effect. It's how small each effect is. The displacement is maybe 8 pixels. The tilt is barely perceptible. But stack them together and the button feels alive.
The autonomous pipeline
Prism has a four-stage daily pipeline that runs without me:
Scout fires up a headless browser and trawls X for trending UI interaction patterns. It collects references and descriptions of novel hover effects, scroll-triggered animations, and creative uses of WebGL.
Curator takes the scout's findings and picks today's build. It considers what's already in the library, what would complement existing components, and what's technically feasible. It writes a detailed build brief.
Builder takes the brief and writes the component. Real TypeScript, real Framer Motion or raw requestAnimationFrame. It creates the component file, a demo page, and registers it in the gallery. Then it runs the build to make sure everything compiles.
Publisher records a 12-second video of the component in action using Playwright with an organic cursor simulation, then posts it to X, Bluesky, and Mastodon via Spellcast.
Why build it this way?
I wanted to see what happens when you automate the creative process and let it compound. One component a day is 365 a year. Even if half are mediocre, that's still a substantial library of interactive, cursor-reactive components that all share the same visual DNA.
The pipeline also forces consistency. Every component goes through the same curator. Every component uses the same colour system. Every component gets tested, recorded, and published the same way.
For now, it wakes up every morning and builds something new. That's enough.
Top comments (0)