Customer.ioAutomate Messaging Everywhere — Startups Get 12 Months Free
Promoted
Balsa establishes a clear contract between your design system and a powerful UI library. Its registry delivers the source code your agents can use, extend, and evolve.
What's great
actually delivers the source code into your repo instead of hiding it behind an npm package, so an agent can read and extend the real component instead of guessing at a black box. registry setup was quick and the components it hands back are clean, readable code, not some generated mess you'd be embarrassed to check in.
What needs improvement
docs are still thin on what happens when the upstream registry updates a component you've already pulled in and modified - would like a clearer story on merging/reconciling those changes instead of just re-copying and diffing by hand.
vs Alternatives
shadcn/uishadcn/ui is the obvious comparison since it pioneered the copy-source-into-repo idea, but it's really just a component collection - it doesn't say much about how those components relate to each other as a system. Balsa frames itself explicitly around the design system contract, which is the part that actually matters once you have agents extending things independently.
Ratings
Ease of use
Reliability
Value for money
Customization
Report
9 views
Dial
this is basically the shadcn model (source code delivered into your repo instead of an npm black box) but pointed at agents instead of humans copy-pasting, which feels like the right instinct given how much agent-written UI code I've seen drift from whatever design system it started from. the question I'd actually want answered before adopting it: once an agent has extended a delivered component and the registry ships an update upstream, what's the story for reconciling the two? shadcn's answer is basically "you're on your own, diff it yourself" - curious if Balsa has anything smarter than that or if it's the same tradeoff.
Balsa UI
@galdayan Hey Gal! Good to know you're using Balsa! That agentic focus really is what I'm trying to achieve with it.
Balsa currently has npx balsa-ui@latest diff <component>. It compares the originally installed source, your local copy, and the current registry version, then reports whether it’s unchanged, local, upstream, or diverged. It currently stops at that classification.
Thanks for raising the gap. 0.8.1 is being published now. The command will also print unified file-level diffs from local source to registry source, and the Balsa agent skill will explicitly instruct agents to run it before updating. Automatic updates will still preserve local and diverged files unless replacement is explicitly forced.
Dial
@pedrobalsa that's a fast turnaround, respect. the "preserve local and diverged unless replacement is forced" default is the right call, that's the one that would've bitten someone silently otherwise. printing the unified diff instead of just the classification label closes the actual gap I was poking at, since right now you'd have to go read the registry source yourself to know if the diff is a one-liner or a rewrite. will try 0.8.1 once it's out.
Balsa UI
@galdayan Yes, Balsa now does exactly that.! 0.8.1 is out.
sorry the docs didn't explain this already, in the next days I'll update the docs also, its a bit sloppy right now.
You can also expect a big increase in the library in the next days.
Balsa UI
@galdayan Thank you!
About the library extension: genuinely new component categories and more component variants for the existing ones. I'll integrate hundreds of open source components to Balsa design system contract and make them available at the library (with author crediting, of course). Then I'll open the library so that users can publish their Balsa integrated components. My objective is providing a library like the 21st one, but all components automatically fit your design system (and any other).