I was working at a startup in 2021 (not my current role) and the company was going through a pivot which meant all of our existing code was being scrapped and we were starting again from scratch.

The main project we'd developed up until that point was a React Native app used on tablets for managing stock and orders. The changes to the business model meant we were about to start work on an online B2B SaaS platform instead.

Most of the dev team (including myself) had never worked on a SaaS application before. We had a mixture of web and native experience, a mixture of Java, Kotlin and JS/TS experience, and we had about six weeks to try to ship something.

So why did we choose to use Chakra UI:

1. We didn't want an extra build step for CSS, because we couldn't afford to spend time debugging build issues and we had limited CSS experience
2. We wanted something that felt like React Native from a code perspective, because that's what we were used to
3. We needed to create something presentable and usable, without design expertise, in a short amount of time, without creating a big mess of tech debt - Chakra UI was 'batteries included' and had a bunch of useful components
4. Some of us had used Material UI in the past and had a bad experience with it - it's too complicated and full of gotchas, and it looks a bit dated

The honeymoon period

Chakra UI was amazingly simple to install and start using. Everything worked first time.

The Chakra UI theme and layout components such as Stack and Center made it easy to build presentable layouts without design expertise. The layout code was simple enough that we could quickly try out different page layouts, so we didn't need to wireframe anything. It was really easy to throw together some basic forms with nice validation states using Form components. I loved using the Skeleton component to make nice loading states. I'd never done anything like this before (I mostly worked on static content sites) so this was really fun.

Something else caught my attention, which I hadn't realised at first. Chakra's theme system (which is based on Styled System Theme Spec) is very powerful. I was surprised that it wasn't a lot more opinionated about styling considering the other benefits the library was offering, but the styling can be completely overridden using a custom theme which can also be extended for styling custom components. I had tried to do a similar thing on a previous project using Styled Components to create white-label components that can be wrapped with different brand themes - Chakra UI is light-years ahead of that approach and I wish it had been around a few years earlier so we could've used it then.

Back to the earlier story - we managed to ship something in time without creating a big mess, which was great. Unfortunately the business itself didn't work out, as is known to happen from time to time with startups.

Chakra UI's theming system was, however, a significant factor in the decision to adopt Chakra UI at the company I've since been working at, and we've used it for all of our projects over the last couple of years.

The last couple of years

We've been using Chakra UI in production for a couple of years now. How has it been so far?

I think it's mostly been great. All of the things that were initially great about Chakra UI are still great about Chakra UI.

I've put together some thoughts below on some of the specific highlights and lowlights I wanted to call out.

The theming system has helped a lot with design/dev alignment and handoff

The Figma kit has provided a good foundation for our internal library file. The theme system in Chakra UI itself is flexible and extensible enough that we haven't been concerned about deviating from the initial defaults. (You can see what our main application looks like on its product page - other companies have demonstrated this to an even greater degree, such as the Figma Conf' 23 site which also uses Chakra UI.)

Chakra UI has worked great for devs at all experience levels and backgrounds

I think Chakra UI is really easy to use, but the real proof of this has been seeing the success that junior/mid and backend engineers have been able to have with it.

I've found that it's been easy to maintain a good standard of code quality compared to the other approaches I've used in the past (CSS, Sass, and Styled Components), which is maybe because the Style Props syntax in Chakra UI is just normal React code - this reduces the cognitive overhead of learning and writing Chakra UI code compared to the alternatives, especially for developers who are new to React and JS/TS.

New patch/minor releases sometimes broke our builds

We've found that occasionally new releases of Chakra UI would cause breakages in our CI/CD builds due to breaking changes creeping into patch/minor releases. These are often fairly small things such as an ARIA role changing on an element causing our tests to fail. Sometimes they are harder to fix or it's unclear whether it's a bug or intended behaviour.

The source code seems overly complex and a bit too spooky for me

I've jumped into the Chakra UI source code a few times to try and fix bugs. I find it scary how much stuff is going on in there. I feel like I can't trust it to not contain weird bugs due to the complexity of the codebase and the number of 3rd-party dependencies. (I think we've come across a few of these bugs, which is why I was looking at the source code to begin with!)

I don't understand how all of the components work, such as the Toast component - it seems like some of this stuff like Standalone Toasts is breaking the rules of React by introducing global state. We've occasionally run into some issues with Chakra UI when writing unit tests (with React Testing Library) and I suspect some of those issues are a result of Chakra UI doing stuff it probably shouldn't be doing under the hood.

Overall, I wish it was more 'basic React' and had less going on. I think this would also help to avoid breaking changes creeping into new minor/patch releases by mistake.

Conclusions

I still love Chakra UI despite its flaws.

I love how accessible it is from a development perspective: it definitely levels the playing field and enables more people to build stuff with confidence and see immediate results from the start, regardless of whether your background is in web, native, backend or whatever. If you can learn to write React code then you can make stuff with Chakra UI.

I'm wondering now what will happen with the project. The maintainers have mostly been working on new projects: Zag, Ark UI and Panda CSS. There were a couple of posts written by Sage explaining the plan with these:

• The future of Chakra UI
• Chakra, Panda and Ark - What's the plan?
• Prepping for a new major release of Chakra (v3)

I think Panda CSS looks great, especially for when you really care about page performance and you want to make extensive use of Server Components - I'd actually really like to try it if I can find a project that demands it. On the other hand, it's an additional CLI tool that has to run both locally and in CI, and I like not having to think about Cascade Layers. The syntax also seems less friendly to me, but I need to try using it in practice.

I still appreciate that Chakra UI doesn't require an extra build step for styling. It's one less thing that can go wrong, and that's saved us time in the long run. For our use case, I also don't really mind that it's not as optimal for end-user performance as some of the other approaches to styling (it uses Emotion under the hood) - this is a worthwhile trade-off for what we gain in developer friendliness.

I think integrating Ark UI into the Chakra UI codebase (as is planned, and I really hope will happen!) could reduce the complexity of the code as well as fixing some of the pain points we ran into, so I'm still holding out for this over the next couple of major releases.

That's all for now!