Despite the promising start, Tamagui proved difficult to set up in our monorepo environment. Performance issues crept in quickly, especially in our Remix-based web app. Tamagui doesn't offer solid support for Remix (if any at all), and integrating the two felt like forcing a square peg into a round hole.

I started suspecting Tamagui was the root cause of our web app’s sluggish performance — the DOM was bloated, and a huge chunk of JS was required just to handle styling. It wasn’t just a bottleneck — it was a full-blown blockade.

The most alarming issue? To get the web app running in development mode, you needed at least 96GB of RAM just to render something. That’s not a typo. For a TypeScript-based app, this is simply unacceptable.

Now, I want to be fair — I don't blame Tamagui entirely. Part of the issue was on us. We didn’t take the time to fully understand the tool or optimize for it. As a startup, time is our most valuable currency, and we couldn’t afford to be stuck in a setup that made fast iteration impossible.

We decided it was time to migrate — but this wasn’t a decision we could approach lightly. A full rewrite on a separate branch would be out of sync within a week. We push code weekly and ship features regularly, so long-lived branches were a no-go.

Here’s the strategy that worked for us:

For styling, Tailwind was the obvious choice: fast, predictable, and built for performance. But for accessible components, we evaluated a few options — Radix UI, Ariakit, and others. In the end, we went with Shadcn because of the developer experience and the primitives were flexible and production-ready (Shadcn uses Radix under the hood).

We tried migrating page-by-page, but that quickly broke due to how tightly styling was coupled to Tamagui's layout logic.

Then we tried migrating one app at a time, but that failed too — we share UI components across both apps, and breaking one app to fix another wasn't a valid option.

Finally, we landed on a strategy that worked:

This approach gave us visibility into how each component was being used, letting us standardize the API and catch edge cases early. It also made it easier to gradually phase out Tamagui without breaking large portions of the app.

We’re about 40% through the migration, and already seeing clear performance gains, especially on the web.

I also created a performance dashboard to help us track real improvements as we continue the migration. We’ll use this data to guide us and make sure the changes we’re making have tangible benefits.

I found another approach that it makes it easier to work with AI code agents: Sort all files that uses tamagui based on the Amout of "Tamagui usage".

Tamagui Usage is not only about how many imports are from the library but mainly how much tightly-coupled are with Tamagui and its API. I calculated the usage based on:

I used AI to help me based on this metrics to create a "Tier Score" for each file that has anything imported from tamagui, and I got a list of files separated by 5-6 tiers.

The first 2-3 tiers were files that the AI agent could migrate by itself with no issues, I reviewed all the migration and it was very accurate.

The higher tiers are left. I'm now preparing the foundation in which I can migrate the more complex components to complete with the migration.