The Sugarcoat Saga: The Genesis of a Personalized UI Library

Hey there, my friend.

If you’re anything like me - always juggling a gazillion digital projects and obsessing over the finest details of user interface - then you’re in for a treat.

I’ve been building my own UI library since the beginning of 2023, and I have to say, it’s been quite a journey.

A journey packed with moments and moments. Excitement while creating new components and seeing them come to life in my projects. Frustration while struggling to bundle the library just to see it crashes the projects using it. Boredom while doing repetitive tasks and writing documentation (all part of the process).

But why?

The Motivation

Let me take you back to six months ago - January 2023 - when I started a sabbatical journey (or so I thought).

I had quit a high-paying freelance job I’ve been working for the past 1.5 years, to take some time off. It was with a health-tech startup where I was hired as a backend developer.

For context, I’m a 10+ years Full-Stack developer, but with a strong affinity towards Frontend land. I love putting together UIs and playing around with UX and interaction.

So, after one year and a half of backend work, I found myself very front-end-thirsty.

I’ve started my new sabbatic journey by revamping my website (the one you’re reading this article on). “Great way to get back into my frontend game”, I say.

Somewhat off-topic: Now I know what you think - sabbatical means “a break from work”. This didn’t sound like a break from work. But for me, it was play and excitement. This is a story for another time.

The Status Quo

The previous version of my website was built and hosted on Webflow - which I’m a fan of - with a $16/month CMS plan for the blogging capabilities.

But at that point, paying $16/month for a fancy, yet simple landing page with a few articles, seemed unreasonable.

So I decided to rebuild it completely from scratch.

My options: NextJs with fancy animation libraries like Framer, and Supabase to serve as a backend and Vercel for the final showdown. All the tools the cool kids on Twitter use these days.

What about UI?

Tailwind… Everybody is using it.

I love it, by the way. But it feels like these days all the new websites and landing pages look the same. You can tell it’s Tailwind right from the hero section.

I don’t blame the framework. This is not a Tailwind rant.

It’s the cool kids using it that don’t try harder with their landing pages, and eventually wind up looking all the same.

Of course, there were other options out there, but I wanted something different for my personal website.

Something I could bring my own personal touch upon.

I’ve wanted to build my own thing.

Hence, Sugarcoat was born, a React UI library built on top of Radix. It’s inspired by the book RefactoringUI, by Adam Wathan and Steve Schoger.

What’s Radix? It’s a powerful set of unstyled components, with built-in accessibility to power up your design system and apps.

I had the book as inspiration and Radix as a foundation; I’ve found my stack.

Time to build.

The Implementation Phase

Building your own UI is a bit like baking your own bread; it’s time-consuming, meticulous, and sometimes boring, but absolutely rewarding.

So I decided to rebuild it from scratch. Buttons, inputs, checkboxes, radio inputs. Each component went through multiple iterations, with constant tweaking and refining until the result satisfied me.

I paid attention to small details while going through the RefactoringUI book, to make sure SugarcoatUI is bringing a cool developer experience and a delightful user experience.

Of course, building my own UI library was not without challenges.

One of the biggest hurdles was bundling the library in a way that it would be performant and compatible with different project setups.

For this, I use the Rollup library.

I spend days experimenting with different bundling configurations, debugging issues, and optimizing performance.

Putting it use

As soon as I had the first set of usable components (some buttons and some layout components), I started to use them on my personal website.

What followed was a few months of parallel work, building the website while creating, tweaking and improving components in the library, as I needed them.

It was a different approach from what I used to do.

I had to think about the component in a generic way, not only how it looks and behaves on my website, but for any project using it.

It was challenging, but fun.

One of the most rewarding moments in this journey was when I finally integrated the entire SugarcoatUI into my website.

Seeing my components come to life and seamlessly blend into the overall design was incredibly satisfying. It felt like I had created something truly unique and personal.

After I finished the new version of my website, some other projects came along in which I started using it.

I had my first working library.

What’s next

“It’s good enough, just put it out there”.

This wasn’t yet another weekend project.

This has also had a psychological impact on me. I had to constantly fight my perfectionism while building it and get to a good-enough version I can call DONE.

The good-enough version is ready, and I’m using it in 3 projects so far.

Of course, this is only the beginning.

I have a cool roadmap full of updates and improvements and a whole array of products that will rely on this baby.

This is the foundation for what I call the Sugarkit ecosystem.

As a quick glimpse of what's on the roadmap:

It’s going to be a sweet ride (sugar, get it?!).

Conclusion

In conclusion, building my own UI library has been a fulfilling and rewarding experience.

It has allowed me to create a unique and personalized UI for my projects and has sparked a sense of accomplishment.

I can't wait to see how Sugarcoat grows and evolves in the future.

Thank you for making it to the end.

In the upcoming articles of this series, I’ll dive deeper into the more nitty-gritty technical stuff of the whole build process (working with Radix, configuring Rollup for bundling, etc)

Stay tuned.