Why we chose Chakra-UI for our design system (part 1)
As front-end developers, we often encounter this situation: “I need that button but with a tooltip” or something along those lines — meaning I need to change my component again and add some more complexity.
I know what you’re thinking:
So to avoid those repetitive situations, we (Engineering, Design, and Product) decided to develop a design system to easily scale and build features faster.
In this 3 part blog post series, I’ll cover:
- The process and choices led us to build our design system with Chakra-UI.
- How we implemented our theme (part 2)
- How we implemented our components and custom components (part 3)
In the first part, we’ll focus on the reasons why a design system is necessary, the prerequisites we had, and what led us to choose Chakra-UI as our component library.
Why do we need a design system?
I have been working as a tech lead for the past year and a half at Melio, a fast-growing fintech B2B startup whose mission is to “keep small businesses in business”. When I first arrived in the middle of 2020 there were about 20 people in engineering, and now we are over 90 (end of 2021).
The growth of engineering meant that we needed to deliver more features faster. I quickly realized that our current front-end codebase wouldn’t allow us to deliver our features in a fast and easy way — we had a lot of components with similar variations, leading to a lot of confusion from the engineering side. We needed a design system component library to help us improve our velocity, both for the design and engineering team.
As engineers, we like to take something that works and apply that to many other variations. But when it comes to the front-end, this paradigm can lead to a really messy codebase.
Let’s see an example:
As you can see a lot of our development time was put into doing the same styling over and over again in different variations, causing messy UI components.
How did we choose a component library?
When it comes to building a design system, there are two common ways to approach it:
1. Build it on our own — from scratch
2. Use a component library and customize it to fit your needs
While building from scratch seems like a good idea, it’s far more costly in terms of time. Because we needed to move fast, we decided to build our design system on top of an existing component library.
Team Work
This is an essential part of this process. Working with people who are “enablers” is very important. For me, my “enablers” were my manager and the design team.
Luckily for me, I have an amazing manager and an amazing design team. I took a big feature that we’d worked on that included a lot of new components, and set the goal of building this feature using a design system. Engineering and Design got together to create a design system that would work for both parties.
4 Prerequisites
- CSS-in-JS based: We were already using a CSS-in-JS solution, and I didn’t want to introduce a bigger change than necessary, let alone the overhead. Most of our engineers were already familiar and happy with it.
- Easily customizable: Melio is a very UI-centric product which means we needed the ability to reach a high level of customization.
- Plug & play: we didn’t want a component library that would leave us dealing with packaging, build, and styling.
- TypeScript: We believe that having typesafe libraries will create a better codebase with fewer bugs.
Options
Given our list, there were a few options
Semantic-UI
This is one of the most popular component libraries out there, that I’d personally had a good experience with. Let’s take a look at some of the pros and cons:
Pros:
- Can be easily customizable using `less` files
- Has a large variety of components that can be used
- Very easy to use
Cons:
- Requires use of `less` files to customize the components
- No responsive out-of-the-box design
- Low browser compatibility — only supports newer versions of browsers
- No ‘CSS-in-JS’ support
Ant Design
Pros:
- TypeScript friendly
- Very comprehensive
- Powerful theme customization in every detail
- Internationalization support
- Great documentation
Cons:
- Theme customization is only done via `less` files
- Accessibility is lacking
- Bundle size is huge — expect a sizable performance impact when using
- Pollutes your CSS — expect to add `!important` to prevent it styling your non-Ant components
Material-UI
Pros:
- Amazing UI components that have a really good look and feel
- Works with `CSS-in-JS`
- Popular with lots of support
- Simple to use (at first)
- The icon library is massive
Cons:
- Customization of components in this library can be really time-consuming and challenging
- Their code has existed for a pretty long time and went through a lot of transformations making it quite hard to understand. Ideally, we’d be able to easily delve into the library code and debug it if needed.
- The packaging sizing of this library can be very high.
- Performance: known to render excessive DOM nodes
There are more component libraries out there, but I’ve focused on the ones that are the most popular and that I’m familiar with.
The Chosen Solution
We discovered a new component library, Chakra-UI. Here’s what we liked:
- Was written with React hooks in mind
- Used `CSS-in-JS`
- Really easy to customize and create your own theme
- Amazing documentation
- Written exclusively in TypeScript! So we know its type-safe 💪
It was like a dream come true. Our only hesitation was that it’s new.
But wait, were we really gonna use a component library that’s only been out there for a year? And base our whole design system on? Hell yes!
Seriously though, it was a risk. To calculate the risk level — we took a week to see if I could implement the design system with Chakra-UI and try to build some of the components needed for a new feature.
And guess what? It worked perfectly!
Next, in part 2 I’ll demonstrate how we created our own theme (typography, colors, sizing, text styles) and customized it to our needs. I’ll also cover some interesting concepts that Chakra-UI has to offer and explore a few special features — stay tuned!
