J—P

In 2017 I built my own utility-first CSS framework. Not because it was trendy or because I wanted to launch “the next big thing,” but simply because I was tired of fighting CSS in real client work. The framework was called Abrusco, and for a long time it quietly did exactly what I needed it to do.

By chance, it appeared just two weeks before Tailwind’s first commit. Same concept. Same direction. Completely different fate.

This isn’t a regret story. It’s more about what I was trying to solve, why it mattered to me, and why I eventually decided to let Abrusco rest.

Where Abrusco Came From

Anyone who’s worked with CSS long enough knows this pain: a project starts out clean, organized, and elegant. Then real life interrupts. Clients request small visual “just a bit different here” changes. Deadlines shorten. Quick fixes slip in. Slowly, the structure collapses into layers of overrides and compromises that nobody is proud of but everyone has to live with.

Utility-first CSS felt like an honest response to that reality rather than a philosophical stance. It’s simply easier — and healthier — to change mr-2 to mr-4 on a single element than to invent yet another exception in a fragile cascade. Around that time I came across Tachyons, Basscss, and a few talks on the subject and the idea clicked hard enough that I wanted a solution I could fully own and shape to my workflow.

So I built one.

What I Wanted Abrusco To Be

Abrusco wasn’t trying to be Tailwind before Tailwind. It was deliberately simpler and more pragmatic:

• CSS-first, no special compiler required
• one stylesheet you could drop in and start working
• solve about 80–90% of layout and UI needs with utilities
• still write normal CSS for special cases
• stay readable and avoid cryptic class nonsense

Because it didn’t rely on a compiler, I leaned heavily on CSS variables. Colors, scales, spacing adjustments — everything could be adjusted without rebuilding anything. Some of my favorite utilities were small but thoughtful details, like padding that automatically compensated for border width so layouts stayed visually stable.

It wasn’t academic. I used Abrusco in real production projects. It served me well.

Meanwhile, Tailwind Became Tailwind

Tailwind appeared with almost the same philosophy but with something I didn’t have: the time and capacity to polish, document, promote, and grow a community around it. The idea was strong, but Tailwind turned it into a platform. They deserve credit for that. Good execution matters.

Watching it evolve, I didn’t feel defeated. I mostly felt validated.

Why I Stopped Pushing Abrusco Forward

The honest answer is priorities. To turn Abrusco into something polished and community-ready would have required a level of commitment, documentation effort, and ecosystem building that simply wasn’t realistic for me at the time. Meanwhile, Tailwind kept improving. Eventually it even adopted directions I liked philosophically, especially as it moved closer to CSS again rather than fighting against it.

At some point, continuing Abrusco would have been about competition for its own sake, not about solving my problems better. That’s when I decided to move on and focus my energy elsewhere — on products, client work, and things that mattered more to me long-term.

Looking Back

Abrusco didn’t become a global framework. It didn’t build a huge community. But it shaped how I think about CSS, about tools, and about building things in general. It proved I wasn’t just following trends; I was already working through the same problems others were just beginning to articulate.

And honestly, that’s enough. It’s part of my story as a builder, and I’m glad I made it.

Abrusco still exists if you’re curious:

• GitHub: https://github.com/lemmon/abrusco
• Homepage: https://abrusco.com/

Sometimes a tool doesn’t need to conquer the world to be meaningful. Sometimes it just needs to solve your problems at the right moment, help you grow, and then gracefully step aside.

That’s exactly what Abrusco did for me.