After I published my last article I received a comment from a friend of mine that stuck with me while talking about (the not quite released) TailwindUI.

well it goes with your new perspective
low effort big results

Jean-Philippe and I have talked about building UI libraries for quite sometime so I was interested in his take on my shift. It started with the default Ghost theme on my refreshed website (which sparked the comment initially) and moved into my fascination with Tailwind. Historically speaking I would be determined to design everything from the ground up myself, but this will be changing as I adopt Tailwind more and more into my workflows.

I plan to use Tailwind on just about every project going forward. I've been tinkering with it passively ever since I discovered it, but never went all-in on it; until now.

This commitment to Tailwind was a big decision because it also meant partially admitting defeat on a passion project of mine over nearly the past two years.

I published the @pqt/components package while learning so many different parts of React, TypeScript, React-JSS and the two brand new tools GitHub Actions and GitHub Package Registry. The git history however is deceiving.

🎨 UI Library History

I started the project in mid 2018 with the intent to make a universal design language framework (bear with me on these buzzwords, I'll qualify them). I noticed design inconsistencies between development projects that spanned various languages, some using frameworks and others not, but all trying their best to share CSS. Though it was often just a copy/paste and make sure the class name didn't conflict with anything else. I've always been an idealist. I hate the corner cutting, no matter how necessary or reasonable. It's my single greatest fault to how I work. Issues aside though, I saw potential for a new developer solution that would possible effect hundreds of developers and – if adopted – millions of customers worldwide simply from the projects I could expose them to.

So I started on the initial version. They were separated by framework, then separated by component logic. This was the case for all of the "supported" frameworks. css, react, vue, custom-elements and react-native to an experimental extent.

This fit the 90% use case and would be focused on the future ahead with the newly introduced Gatsby static site generator built using React. Conceptually I still believe this approach is fantastic, but at the time I had so many hurdles and pitfalls to learn about before I started to understand the flow of other major component libraries and design systems like Vuetify and GitHub Primer.

User Interface Components available in HTML, CSS, React and Vue - pqt-graveyard/ui

After a full year of development, 172 releases all the way up to 3.0.2, learning all sorts of important things like Advanced Webpack configurations, Lerna, the true legalities to picking the right OSS License, Azure Pipelines, TypeScript shared configurations, and the ins-and-outs of PostCSS, I archived the repository to start fresh with the new found knowledge to avoid future pitfalls (in hindsight this was a naive decision but since you can't delete git history, I guess I just have to live with it).

🎬 Take 2

The successor – hilariously – looks nearly identical to the initial project in folder structure, though they ultimately were very different in how they reached the final result.

🎨 User Interface Components available in HTML, CSS, React, React Native, Vue and Custom Elements - pqt-graveyard/ui-old

5 months of work and effort (considerably shorter than the 12 months previously!) I no longer had the same use-case as initially. I was no longer involved in the same projects that drove the initial proof-of-concept. I only used React in my projects so I didn't need (nor want) to maintain Vue, Custom Elements, and React Native myself when I didn't know when/if I'd ever really use them.

📦 Endgame

The final project started as "Paquette UI", if you've checked out the links to the other repositories you'll see that was just about the only constant. Of course I changed that to the now more appropriate react-components and focused on pairing the stylings directly to the components. I'll spare the elongated details but 2 more repositories later I end up with a component library that I'm finally proud of.

User Interface Components for the Paquette design system including hooks, style primatives and style hooks. - pqt-graveyard/react-components
React (TypeScript) user interface & component library, including utility hooks, theming and style hooks. - pqt/components

Even the most current repository has a lot of work to go before I could use it in a production-ready application, 2 years in, I've only spun my wheels. Learning is important and I can bring this new found knowledge to any component library or design team I work with, but as for produced works, it's not even a stable package yet. It's disappointing to me.


Finally! This is where tailwind levels out the whole equation. There's already enough community resources that I don't need to talk about how amazing tailwind already is and how it's the perfect fit but let's revisit that comment from before.

well it goes with your new perspective
low effort big results

It's a common-sense perspective, but I had lost sight of that. Focusing on fashion over function. Tailwind helps me avoid that, and Tailwind UI can help me eliminate a lot of design decisions almost entirely across the board. This will save me tons of functionality building time, without a loss of aesthetic pleasure.

I can confidently say that I will be an early adopter of Tailwind UI with a few projects that have been planned where development has not started.

How To Use Tailwind CSS with Next.js
How to install Tailwind in a Next.js project.
Installation - Tailwind CSS
Quick start guide for installing and configuring Tailwind CSS.

If you haven't already, checkout the Tailwind UI website. Maybe it will help you the same way it's helped me already on the projects I have involved it in.