Hyperiux Vault - The Interaction Layer Your Website is Missing
by•
Vault by Hyperiux is a source-first interaction effects library for React and Next.js. Add scroll effects, cursor reactions, text reveals, page transitions, loaders, and WebGL-style atmospheres without starting from scratch. Preview an effect, install it, edit the source, and ship websites that feel as premium as they look.
Replies
the source-owned angle (copy it, edit it, it's yours) is the right call given the shadcn precedent. but that model has a natural tension with maintenance - once I've copied an effect into my project and customized it, if you later ship a bug fix or perf improvement to that same effect upstream, is there any path for me to pull that in, or am I just permanently forked from that point on and on my own for updates?
Great question, @galdayan! This is a real trade-off with source-owned code. Right now, once you customize an effect, it's basically your own fork. We'll never touch it silently, but that also means upstream fixes need to be applied manually. We don't think "you own it" should mean "you're on your own," though. Fixing that is high on our roadmap.
The plan is to turn the CLI into a lightweight sync layer. Each effect carries version metadata, so something like `npx hyperiux check` can flag when there's an upstream bug fix or perf improvement waiting. Then an interactive diff (think Git) shows exactly what changed, so you can cherry-pick what you want instead of your customization getting overwritten.
So the honest answer is - yes, updates are manual today. The direction we’re building toward is opt-in, reviewable synchronization and not silent auto-updates, and not permanent abandonment after copy-paste. Hope this helps!
@bhaskarvarshney that's a much better answer than I expected honestly, most tools in this space just wave their hands at the fork problem. one thing I'm curious about - the interactive diff works fine when the upstream fix touches lines you never touched. what happens when the upstream fix is literally on the exact line you customized, like they changed the same easing curve you tweaked? does it fall back to something like git conflict markers, or does it just skip that hunk and tell you to eyeball it yourself?
@galdayan Our intended direction is a three-way comparison between the original version you installed, your current customized version, and the latest upstream version. If your local copy and the upstream update changed the same section, the upgrade flow would flag it as a conflict and show all three versions side by side: the original, your edit, and the upstream fix. You could then keep your version, accept the upstream version, or manually combine them.
Implementation wise - Git style conflict markers could exist as a fallback, but ideally the interactive flow would surface and resolve the conflict before writing anything back to the file. The exact UX is still being worked through, but silent overwrites are firmly off the table. :)
@bhaskarvarshney "silent overwrites are firmly off the table" is the part that matters most, even if the exact UX isn't nailed down yet, that's a commitment you can hold the team to later. three-way diff before any write is the right default position to be building toward. curious to see what the conflict UI actually looks like once it ships.