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.
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?
Yes. OKLCH is actually MORE intuitive when creating shades because it's based around human perception. It also supports wide color spaces like P3, where rgba is, IIRC, bound to sRGB.
The utility of these color spaces and color functions isn't lost just because LLM. Color systems haven't gone anywhere.
Would highly recommend reading up on OKLCH if you haven't already. A lot of people put a lot of effort into promoting this and bringing it to baseline..
Well I use it on my personal site: the colors change with the weather and seasons [1]. Oklab’s so-what is that the hues are perceptually a uniform brightness, unlike HSL (which I started with) where blues and reds look a lot brighter than greens and yellows at the same saturation/lightness.
So in my case where color shifting is happening, Oklab actually helps. I don’t know how it’s better than HSL for simple UI elements unless maybe you can get physically brighter values that pop out more on certain screens.
Yes, since the last couple of years. I tend to help architect and scaffold large projects that goes on for years, and changes a lot of developers, designers in its lifecycle. I was pretty confident of moving to OKLCH about 4-years ago and have have had it as default. OKLCH values are now the source of truth for these projects, and other design elements — all the way to Powerpoints (HEX/RGB) and Print (CMYK) are derived from OKLCH. There are variations but most people don’t even know the difference.
This started way back working with my long-term business partner and he built a pretty good tool to help visualize and tinker with it.
Yes. And I'd argue it's more intuitive if all colors with the same lightness value are in fact the same lightness. Hue and chroma are pretty easy to understand too.
> 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.
- 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/
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
Thank you Lucas Larroche for building Pico CSS and sharing it with us.
We’re actively maintaining Blades CSS on GitHub and Discord, and would love Community feedback there.
We also set up a dedicated page outlining key details: https://blades.dev/css/pico/
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?
Yes. OKLCH is actually MORE intuitive when creating shades because it's based around human perception. It also supports wide color spaces like P3, where rgba is, IIRC, bound to sRGB.
The utility of these color spaces and color functions isn't lost just because LLM. Color systems haven't gone anywhere.
Would highly recommend reading up on OKLCH if you haven't already. A lot of people put a lot of effort into promoting this and bringing it to baseline..
So in my case where color shifting is happening, Oklab actually helps. I don’t know how it’s better than HSL for simple UI elements unless maybe you can get physically brighter values that pop out more on certain screens.
[1]: https://joeldueck.com
I love OKLCH. Awkward to say, beautiful to look at.
This started way back working with my long-term business partner and he built a pretty good tool to help visualize and tinker with it.
Website https://colorcolor.in
Source https://github.com/saneef/color-color
https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...
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.
Does anyone know a similar project doing this?
Already plain modern CSS instead of Sass, has Popover API, and CSS layers for individual components, OKLCH colors are on the way.
Drop-in compatible with Pico CSS (via underlying fork)