Migrating From Tailwind and Radix to VivekUI

If Tailwind and Radix are working for your team, this is not a reason to change. A migration costs weeks and delivers no user-visible feature, and 'fewer dependencies' is a weak justification on its own.

The cases where it is worth considering: your team spends real time on build configuration, you want Server Components and keep hitting client boundaries, or you are starting a new project and choosing fresh. Migrating a working codebase for architectural tidiness rarely repays the cost.

Tailwind is a build step producing utility classes. VivekUI is a stylesheet plus components. They do not conflict, so you can install VivekUI alongside your existing setup and adopt it incrementally without a flag day.

That is what makes a staged migration possible. Every step below is independently shippable and independently revertible, which is the property you want in a refactor that touches every screen.

Build the next new page with VivekUI and change nothing that exists. This gives you a real assessment of whether the component surface covers your needs, on work you had to do anyway, at no migration cost.

Pay attention to what you reach for and cannot find. If you hit three gaps in one page, that is your answer and you have spent a day rather than a month finding it.

Move one component type at a time across the app — every dialog, then every form field, then every table. Grouping by component rather than by page means each change is mechanically similar and easy to review.

Start where the behaviour is hardest, which is usually dialogs and comboboxes, because that is where you gain the most: focus trapping, scroll lock, inert backgrounds and `aria-activedescendant` handling stop being your code. Buttons and cards can wait, since your existing ones are probably fine.

Map your Tailwind theme values onto CSS custom properties. This is usually a mechanical translation of a colour palette and a spacing scale into a variable block, and it is where the two systems stop being parallel and start being one.

Only after that, remove the build plumbing: the Tailwind config, the PostCSS plugin, the purge configuration. Delete it last, because until the last utility class is gone the build step is still doing real work, and removing it early produces a confusing broken state.

Arbitrary utility classes. `mt-[13px]` has no equivalent, and you will write CSS instead. For teams fluent in Tailwind this is the change that grates most, because a one-off spacing tweak becomes a class in a stylesheet rather than a token in the markup.

You will also miss Radix's maturity. It has years of production exposure and edge cases found by an enormous user base; any solo implementation of the same patterns has less. And the Tailwind ecosystem — plugins, presets, the sheer volume of examples — has no equivalent here. Weigh those honestly rather than only counting dependencies removed.

Finally, weigh the bus factor. Tailwind and Radix have teams and corporate backing; this library currently has one maintainer. MIT licensing means you can always fork it, and zero dependencies means the surface you would inherit is small — but that is a mitigation, not an equivalence, and it belongs in the decision.