PicoCSS, the mostly classless CSS framework I've used for years, is no longer being maintained.
According to its official maintenance notice, v2.1.1 will be the final release.
I use PicoCSS on my own site and in several other projects, and until now it remained near the top of my list for new ones.
I've customized it with Sass and filled in gaps with my own styles, so it isn't something I'm eager to leave behind.
The releases weren't particularly frequent, but the jump from v1 to v2 brought meaningful changes to the appearance, accessibility, color palette, and customization system.
I'd been looking forward to seeing where v3 might take it.
And yet here is a project with roughly 17,000 GitHub stars reaching the end of maintenance.
Stars don't guarantee sustainability, of course, but I didn't expect a framework with that much support to end this way.
I like being able to write straightforward HTML
What I liked most about PicoCSS was how naturally it let me write HTML.
I can see the value in utility-first approaches such as Tailwind CSS, but having long lists of styling classes in my markup has never appealed to me.
I'd rather keep HTML simple and semantic, and let CSS handle presentation.
With PicoCSS, standard headings, buttons, and form elements already look decent.
You can add classes where necessary without having to learn a framework-specific way of expressing everything.
I've always been drawn to classless CSS frameworks, and PicoCSS was the one that felt most practical after trying different options.
A Zenn article, “The Magic of Pico CSS That Makes Design Delightful” (in Japanese), also helped put into words what appealed to me about it.
What if I built my own?
When I heard the maintenance news, I briefly considered making something similar myself.
It could carry forward what I liked about PicoCSS while using newer CSS features such as light-dark(), oklch(), @layer, and CSS nesting.
A small classless stylesheet without Sass sounded like an enjoyable project.
But building something and maintaining it are different commitments.
There are browser changes to follow, bugs to fix, and compatibility to keep up.
A growing community could also mean taking on community maintenance.
I might have the enthusiasm now, but I can't promise my future self will.
So I decided to appreciate the work that went into PicoCSS and look for an existing alternative before writing my own.
Looking at the alternatives
I wanted something that makes good use of standard HTML, provides a sensible appearance out of the box, and works for forms and small web apps.
Classless operation, a small footprint, and easy customization would be bonuses.
I don't want a long list of framework-specific elements or conventions to memorize.
I looked at Simple.css, MVP.css, Blades CSS, and Beer CSS.
Simple.css and MVP.css are approachable, but for the form-heavy screens and small applications I build, I'd prefer a few more ready-made pieces.
Blades CSS is a particularly natural migration candidate because it's a fork of PicoCSS.
It advertises compatibility and offers a setup where switching the stylesheet may be enough.
That is appealing if I want to preserve my markup, although I'd still need to check what happens to the Sass customization on my own site.
For now, though, I want to consider a longer-term direction rather than simply replace PicoCSS with the closest equivalent.
I've also used Beer CSS a little in the past.
I liked the idea of expressing Material Design through relatively straightforward HTML, but in practice its conventions were harder for me to adapt to the way I wanted to work.
I keep coming back to the same preference: I don't want to rewrite HTML just to achieve a particular visual style.
Oat UI looks promising
That led me to Oat UI.
It reached v1.0.0 in October 2026 and already has more than 5,000 GitHub stars.
That's encouraging for a young project, though PicoCSS is a reminder that popularity says little about long-term maintenance.
From reading the documentation, Oat UI seems to value semantic HTML, a lightweight approach, and minimal dependencies.
It uses standard elements and attributes where practical, with additional UI components where needed.
That feels close to the philosophy that drew me to PicoCSS.
It also includes interactive pieces suited to web applications, not just basic form styling.
Some of the things I've been building myself around PicoCSS might be covered by Oat UI.
I'm not claiming Oat UI is PicoCSS's successor.
It's simply a project whose design choices appeal to me.
It isn't entirely plain HTML: some components require custom attributes or Web Components.
I'd like to see how those feel in actual use.
As native features such as <details>, <dialog>, and the Popover API become more capable and widely adopted, I hope the library can rely on them even more.
And in a rather silly coincidence, after Beer CSS, the next candidate to catch my eye is Oat UI.
Apparently I'm staying with grain-themed frameworks.
The migration so far
I've started migrating some of my work from PicoCSS to Oat UI, and so far the process has felt fairly straightforward.
PicoCSS didn't require many framework-specific conventions to begin with, and Oat UI also makes good use of standard HTML, so much of the markup can stay familiar.
Nothing has been released yet, and the migration isn't finished.
There are some small visual differences, but rather than reproduce the old design pixel for pixel, I'm willing to treat those changes as part of modernizing the UI.
I'll keep an eye on how much custom CSS and framework-specific markup the switch actually saves.
It's disappointing to see a tool I liked reach the end of maintenance.
But that doesn't mean giving up the principles that made me choose it.
PicoCSS's departure has been a chance to think again about what matters to me when building for the web.
Comments