logoalt Hacker News

Pico CSS is no longer maintained

144 points • by henrid • today at 1:58 AM • 61 comments • view on HN

Comments

fodkodrasz • today at 10:28 AM

I'm sad to read this, but the authors know what is best for them, and what their priorities are. I'm really grateful for their work, I found Pico a few years ago, when I needed a minimal page (some status page for an embedded system) super quickly, and I had more than enough from the Bootstrap div soup, and invested half of the available time to research alternatives in - as I learnt the correct therm for my preference then - semantic html.

It was a blast, super simple markup, mostly good defaults, I really enjoyed it.

I hope the best for them, and I hope some fork may get some traction, as Pico was my goto framework for small stuff one needs to do every now and then, and I really don't like the tailwind approach.

shubhamjain • today at 6:03 AM

> To stay relevant, Pico CSS would need a full rewrite: plain modern CSS instead of Sass, built on features it doesn't use today (OKLCH colors, cascade layers, Popover, anchor positioning) with fallbacks for older browsers

Why? Why? Why? I hate how everyone seems convinced they need to adopt the latest and greatest browser features just to stay relevant. I hate oklch and I hate Tailwind popularized it. I don't care how scientifically accurate it is at representing human color perception. It's a PITA to understand a new type of color system, and learn to tweak it, especially when HSL/RGB just worked fine.

sphars • today at 3:10 AM

Some recent alternatives/successors/forks that are in the same vein as Pico

- Nimble: https://leftium.github.io/nimble.css/demo/pico.html

- Sumi.css: https://vladocar.github.io/Sumi.css/docs.html

- Blades: https://github.com/anyblades/blades

- Oat: https://oat.ink/

➕ show 2 replies
eterps • today at 2:33 AM

I really enjoyed using Pico CSS, but I understand the choice.

Thank you Lucas Larroche for building Pico CSS and sharing it with us.

Brajeshwar • today at 3:42 AM

First, I confess that I had built quite a lot of CSS Frameworks and Design Systems in my early developer life. So, this is going to be more of a personal experience.

Ever since Coding Assistant LLMs became pretty good (2025-Q4 - 2026-Q1), I feel that it makes very little sense to continue to use pre-defined CSS Frameworks that 'has everything.' Of course, it is still OK if the general team decides on one, and they are OK (such as the Tailwinds, MUI of the frontend world.)

I have used Foundation[1] and Bourbon[2] extensively. Mostly because I can break it down and take just what the project needs and keep it within a low CSS budget for any project.

With that in mind, in the 10+ projects that started for some of the biggest brands of the world, I just defined the CSS framework, design systems, design token, with room for extension as the project grows. Claude Code is my tool of choice for now and I just let it run overnight, tweak as the project scaffolds and finally takes about less than a week to have a complete CSS framework in just plain CSS, and JavaScript where it needs to talk to the broader frontend.

1. https://get.foundation

2. https://www.bourbon.io

➕ show 1 reply
Retr0id • today at 2:19 AM

https://github.com/anyblades/blades seems to be a continuation in the same spirit

➕ show 1 reply
verandaguy • today at 3:08 AM

I haven't done frontend dev in a while, but one thing stands out to me here... they call out using OKLCH colours, which I had to look up. (For the uninitiated, this is a cylindrical projection of the also-new-to-me Oklab colour space, which appears largely unrelated to the older CIE L*a*b* colour space).

Do people actually use this? In particular, before LLMs ate the world, I mean. When I did frontend, it was hex, or if you felt fancy, `rgba(...)` (though at that point named colours had mostly fallen out of style).

Is using these less-intuitive colour encodings made more practical through the use of CSS variables?

➕ show 7 replies
steve_adams_86 • today at 2:17 AM

A little sad in a way, but this seems like the right call. I haven't used Pico in a very long time, and I don't think I'd choose it today.

➕ show 1 reply
suhlig • today at 7:31 AM

Thank you very much for your stewardship over the years. And kudos for not just letting it rot, but communicating clearly, and closing it down responsibly.

gajus • today at 6:18 AM

Been working on https://bamboocss.com/ for couple of months.

It's build-time, Rust/Oxc, type-safe, zero-runtime CSS-in-JS, with per-route CSS splitting.

➕ show 1 reply
prokopton • today at 6:41 AM

I love plain old Vanilla CSS. Pre-processor-free for a couple years now and don't miss anything.

j45 • today at 3:37 AM

Pico is a great little library.

Thank you to the developer and maintainer

For what it’s worth I had to force Claude early in to use pico and not ever generate react or ornate tailwind.

Pico is extraordinary for standalone tools where ai can’t let complexity build out of control.

Maybe there’s other options but pico is what got it done, and vanilla LLMs has a hard time keeping something this simple and elegant and flexible.

➕ show 1 reply
mhd • today at 8:43 AM

I miss 960px grid systems…

vachina • today at 7:29 AM

Thank you for the training data

u8 • today at 2:28 AM

What a tragedy.

➕ show 1 reply
smlx • today at 2:48 AM

> To stay relevant, Pico CSS would need a full rewrite: plain modern CSS instead of Sass, built on features it doesn't use today (OKLCH colors, cascade layers, Popover, anchor positioning) with fallbacks for older browsers, and a native compiler that strips unused CSS and makes customization easy.

Does anyone know a similar project doing this?

➕ show 2 replies
pjarrow • today at 3:52 AM

[flagged]

hexjy • today at 7:48 AM

[flagged]

yje07039 • today at 4:22 AM

[dead]

minfazhai • today at 2:40 AM

[flagged]

wetpaws • today at 2:43 AM

[dead]

psadri • today at 2:44 AM

Hmm. I use pico. They could use an agent to modernize it!

➕ show 1 reply