Chakra UI

In late May, I was assigned to an IBM Consulting client in New York City. This meant my first onsite assignment (ever), my first time back in any office in more than two years, and also one of my biggest challenges so far at this job.

The client’s first big need was to build a prototype of app that could be used to demo to stakeholders and secure additional support and funding. Once I was fully onboarded, I had just over 3 weeks to build it.

I knew that using a framework would speed delivery of a consistent UI across multiple pages of the app, and I considered other frameworks before settling on Chakra-UI.

Why not something more “mainstream?” I’m glad you asked. My selection was based on the following criteria:

Chakra is:

• fast to develop with
• built on a standard of attrbibutes that is intuitive; after looking up the shorthand for a few properties I was trying to add, I was able to guess others without having to go back to the docs
• simple enough to get started, and continue at that level, or learn more advanced functionality

Chakra is not:

• super opinionated about the look of UI elements. it looks basic on purpose
• gate-keepy. you don’t have to learn advanced syntax in order to make anything work. and it doesn’t block or replace normal CSS. it feels like an extension to the knowledge you already have of CSS

I figured other benefits as well that didn’t come into play until later. Want to add more developers to the project? Just point them to the docs, they’re great.

The conclusion to the story is predictable, but to spell it out: the ‘living’ prototype was a hit, the demo went well, the project continues. For a lot of complicated reasons (“enterprise”) the production site wasn’t built using Chakra. But for a smaller company or project, or one with more green-field autonomy, this could have easily become the codebase for the “real” version.