> 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.
I don't get any of this hate. oklch makes it really easy to create new tones from a starting point and stuff like anchor positioning also makes it really easy to place absolutely-positioned things. So it's not like those "latest and greatest browser features" are there just to complicate your life, but actually the contrary.
This just seems to me like (1) not wanting to learn new things, (2) a logical fallacy because the conclusion that those changes are to "stay relevant" and not to make the life of any future mantainer easier, and (3) fear of the new (https://en.wikipedia.org/wiki/Neophobia)
If you asked me to pick out bright bold blue (#0000FF) and told me the format was "Lightness Chroma Hue" with valid ranges, I would guess "0.5 1.0 240". Not only is this "not visible on any monitor" by a very large margin but the oklch.com calculator states the spec fallback color is Dell logo blue and not bright at all while browsers will render "vibrant purple".
There's not "120 degrees of red, 120 degrees of green, 120 degrees of blue", so blue is not 240. Actual bright blue is hue 264. The "0-255 RGB" bright blue is 0.452 lightness, and max chroma on a really good monitor is something like 0.33. The lightness mostly makes sense, right? 0.5 is halfway between totally dark and completely washed out.
"Ok, so chroma tops at at 0.33" not so fast. You can crank up the chroma to 0.40 and still get either magenta (where lightness is around 0.74) or green (lightness around 0.78). So now you need to know a valid, nonlinear lightness range for each band of colors, because midpoint blue is different than midpoint red which is different from midpoint green.
From greyscale luminosity calculations and knowing about subpixels and bayer filters, I would've been able to guess that green is the color with the highest chroma, but then there's bright magenta, neck-and-neck. Oh. Until I move the lightness slider down on the web color picker, and then everything (especially peaks) in the chroma channel shifts around dramatically... So much for intuition.
While OKLCH makes it really convenient to select colors with properties you like along a gradient, the nonlinearity means either memorizing a bunch of base colors, using a color picker, or converting from a system that is "actually" intuitive. I can't really look at a trio of OKLCH numbers and predict the output color like I'd be able to with RGB, although this is mindful that RGB is also not linear (for the exact opposite reason as OKLCH) and I can only do that from decades of experience.
I'll concede that magenta and bright green and bold blue don't really have a place on the world wide web other than in a company logo, so these are outliers. Still, the OKLCH format is not what I'd call intuitive to a total beginner.
(Also, I'd very much not like to implement OKLCH calculations on a microcontroller until lighting companies start selling OKLCH LEDs.)
Thank you for putting in words why I struggle with OKLCH. I found it non-intuitive to learn as a human being despite its "gradient" advantage. I still stick to HSL. (Though I wish web had adopted HSB)
> So it's not like those "latest and greatest browser features" are there just to complicate your life, but actually the contrary.
What justification do you have to adopt and replace this with existing solutions with such urgency? Have you researched its compatibility? Are you providing any fallback?
This just seem to like 1) you are not applying your mind why you want this, 2) faulty premise that it makes it easier, because in reality your software never reaches a point of maturity, where its just "done", and 3) shiny object syndrome (https://en.wikipedia.org/wiki/Shiny_object_syndrome)
Respectfully it's up to the maintainer who decides where they think it shoudl go.
After I read the same I thought, ok, that's what _they_ wanted to do.
Me? I'd love to see what could be rewritten to be 100% future proofed for as many years as possible. But see what that did? I have to share, and see if anyone else already thought of this (I doubt I'm the first ever to have this thought), and maybe, I'll be lucky enough to benefit from someone exploring it already, before I decide to put on a jedi robe and wave my hands to use the force to move AI around.
OKLCH is as you say unambiguously better and IMO easier to understand than RGB, where choosing relative adaptations of colour is basically pretty fraught.
Alas, in terms of the software people use to mock up designs, very few desktop apps support it. HSL is, for now, the more practical option.
Perceptual colour spaces are emphatically not “simply better”. They’re better for most colour mixing (which is of more limited application than you may think) and for some sorts of intuitions, but their shape is far more complex, not mapping to the actual screen gamut in any predictable way, making them highly obnoxious for colour selection, because it’s super easy to fall out-of-gamut without realising it (and I don’t know of any tooling that draws your attention to when that happens) so that its entire purpose is compromised, and they’re downright atrocious at handling vivid (near edge-of-gamut) colours.
Take bright yellows as one of the worst examples. Basically the only thing you can do with them is reduce the chroma: any other change will take you out of gamut. As the most extreme case, #ff0 is approximately oklch(0.968 0.211 109.77), and the following minuscule modifications will take it out of gamut: L + 0.0002, L − 0.0001, C + 0.0002, H − 0.009 or H + 0.025.
Are RGB and HSL color models all broken and useless? Yes, I know their limitations. But of all graphical software I use daily. only GIMP supports LCh, and using it is pretty unintuitive.
I see how position-anchor and stuff are coll for complex layouts, but they have poor support on low-power mobile browsers, and, frankly, are not that useful for a minimalistic CSS framework. If you want complicated layouts with non-obvious anchoring rules, you're not the target audience.
Cascade layers are very useful for complex designs with many independently added stylesheets. They would be great to have. OTOH again, if you need this level of complexity, you're likely not the target audience of a pico-sized CSS framework.
I would say that a minimalist framework should make judicious use of CSS3 features, and not try to be excessively clever. In reliable engineering, being smart often means avoiding being clever.
Look all I can say is now that we have LLMs, you'd have to put a gun to my head to target the browser. Worst application platform imaginable. Somehow it's also become a pretty bad document browser.
I was a big fan of pico! Such an inspiration. I created https://github.com/lekoala/actual-css as an attempt to get something modern yet as compatible as possible with older browsers (still ended up using popover because it's such a welcome addition to modern css). I'm still not sure modern css frameworks need to use layers (it breaks on older browsers) or anchor positioning (minimal js does the job, sometimes even better, and again: more compatible).
It's broken in the exact same way in the last version of Vivaldi that works on Windows <10.
From a quick look at the second horizontal strip that starts "what is this?", and without wasting time doing too much digging, it appears to be ultimately caused by using a grid layout for a heading followed by a few paragraphs, all of which fill the available (constrained) width, which amounts to one of the absolute simplest layouts possible in CSS - block. Last time I saw something similar, albeit with flexbox not grid, it was from a junior developer who appeared to have only learned flexbox and nothing else.
As a quick semi-fix, just disabling grid-template-columns on .base-layout is enough to fix almost everything except the constrained width.
Sounds like that older Vivaldi version does not support CSS nesting. I looked into it. I'm assuming you are using Vivaldi 5.6 which uses Chromium 108, native CSS nesting became supported in Chromium 112.
It uses CSS Grid to create a centered, width-constrained content area while allowing individual elements to break out of it or span the full viewport width. This provides a flexible, consistent layout without the need for additional wrapper elements in the HTML.
CSS nesting has had full browser support for more than 3 years now, I recommend updating. I'll also add fallback for older browsers, but the Grid layout itself isn't the issue.
Yes, that's right. I thought I'd try it in that older browser that I still happen to have installed, as the user above didn't immediately let us know what that mobile browser was. It may or may not help by at least giving you a browser version you can use to test. As I mentioned somewhere else, it makes sense to use some sort of older browser as a proxy for older browsers in general, when testing.
Developers are always looking for new ways to do what we've always done, often using more technically complicated ways to recreate the simplest things. It's fun from the puzzle-solving point of view, but your choice of earliest browsers you want to support depends on your user base.
I built https://purecss.com (not pure-css.github.io), maybe you'd find the site helpful? Currently it's 77 CSS patterns and another ~20 coming in the next few weeks. Each have a demo and the code underneath. Check it out and let me know if there's something you can think of that you'd like to see there. Happy CSS'ing!
Yea, exactly and thanks! I love making CSS things that were previously only possible with JavaScript. Carouses, accordions, toggle switches, etc. I love how powerful CSS has become over the last few years!
Yes it is a pain. But the whole thing is like two pages, so I^H my LLM just reads it. I used to read it. It was ok readable (and I'm not very good at CSS).
Ios 13.6 in my case, which was released just 6 yrs ago, 2020. For some context, flexbox gap was added in ios14.1, released in 2021. So iOS 13.6 was still usable atleast couple of years beyond that. So such frameworks utterly failing on such browsers is hilarious, given that they market themselves as minimal.
People keep forgetting that css3 was announced in 1999. And adoption roughly started from 2010. The css3 of that time is not the same as css3 you get to see in latest browsers. These minimal css frameworks are really useless if you don’t know what css3 features you are writing and who you are targeting.
And, I Haven’t even tested those in less capable browsers like dillo or netsurf, but I doubt they will even work there.
If you start looking into browser market share, you will quickly realise that there are millions of worldwide users who can’t use the web normally.
> When you say something is minimal, you are implying that what little you provide will also work.
No you do not. You just saying it’s got very little code and/or very few features.
Support for older browsers might not be one of those features. Which means this minimal frameworks isn’t suited for the kind of projects where that kind of compatibility is a concern.
If you look outside of CSS (and particularly web development as a whole) you’ll find a plethora of minimal frameworks that intentionally make compatibility trade offs.
As you're mainly complaining about CSS layout features being used here:
For a long time we were forced to use the ugliest hacks imaginable to get to the nice (responsive, design-minimalist(!)) layouts we wanted, because CSS layout tools were utter archaic bs, for years on end, because browsers iterated so slowly.
Then things started speeding up, and we're getting to make better websites (and apps!) that are way easier to design (with the correct design theory equivalents), implenent (with less code) and easier to maintain (i.e., understand). And you're not missing out if you just keep your browser up to date.
I know it sucks if you're on an unsupported device that doesn't get any updates, fair.
But let's face it: 99% of the population is better off security-wise when we're not enabling them to run unpatched devices forever.
Security updates have nothing to do with level of support for css3 modules.
Much of the issues of layout were already solved more than 12 yrs back, ie when css3 became mainstream.
The issue is devs are unaware about different levels of css3 or just plain ignorant about it.
Are you aware about the different levels of css3? Are you even aware there are levels to css3? Why are these frameworks not listing them and simply saying that they comply with web standards? Which specific web standards do they comply?
Any new css3 feature should have a fallback if they say they comply to web standards, which these frameworks don’t add.
To be fair on this particular point, talking about iOS Safari before version 14 isn't "some random old build". It depends on your own users, but I saw plenty of 6-year-old iPhone user agents in the web logs when dealing with a doctor's surgeries app.
They don’t unfortunately but it is a good reference for me to check how it looks on previous versions of browsers and less powerful devices. That way I know if the UI or UX needs improvement.
ios updates unfortunately ties everything to a single batch. Unlike android. I have an older blackberry, that still gets latest app updates.
What is even hilarious is ads render with pixel perfection on older devices. So for some reason, ad networks care about browser compatibility than devs putting the same ads on their incompatible website.
Exactly. Ad creators know that the purpose of what they're building is more important than their personal dev experience of using shiny new tools. It's such a shame the fashion is the other way for so many web developers, largely the younger and less experienced ones.
And yes, it makes sense to use one particular old browser as a general proxy for older browsers in general, so people shouldn't get hung up on the particular version of Safari you happened to mention.
> It's such a shame the fashion is the other way for so many web developers, largely the younger and less experienced ones.
I don’t care about what’s trendy, but using outdated, insecure browsers to surf the web is just plain stupid. Even more, expecting developers to waste time working around all the bugs in those old browsers is just insane. I do the opposite: as soon as a browser reaches EOL I drop the support. Don't encourage lazy admins and bad habits.
It's a shame such an arrogant attitude exists, to call everyone who can't afford to replace their iPhone with a newer model "stupid". And developers really should know better than to fall for the marketing nonsense that anything more than 5 minutes old is "insecure".
> expecting developers to waste time working around all the bugs in those old browsers is just insane
What bugs? The ancestor posts are talking about frameworks immediately using features that were just added to browsers - i.e. more recently than those older versions. Nothing at all to do with bugs. Can you help us to see what you've misunderstood here? Perhaps not dismissing users as "stupid", developers as "insane", and admins (?) as "lazy", would be a good starting point.
I guess at that point I have to assume you have no idea about front-end development. Otherwise you would know what a pain in the ass old browsers with their inconsistencies are (e.g. remember the struggle with the early flexbox implementations?).
I don't disagree! But at the same time, part of our job as web developers involves acknowledging the reality of what our users actually do.
What do early flexbox implementations (something like 12-15 years ago?) have to do with anything? We're not talking about browsers as old as that! They weren't even bugs, they were early implementations of early versions of the standard, so who exactly is the one with no idea here? That level of browser inconsistencies is long gone.
Those of us with years of experience of building user-centric front-ends are not the ones who jump to use new browser features too quickly.
I won't be continuing this conversation, due to the general arrogance and condescension displayed in your posts - following "stupid", "insane" and "lazy" with "bad decision", "where have you been" and "you have no idea".
With AI he could have made the updates to "stay relevant" as he called it. That seems easier than ever. PicoCSS has brand recognition that shouldn't be throw away.
> Today, AI can generate lightweight, standalone, accessible HTML with just the CSS it needs, so a Minimal CSS Framework for Semantic HTML matters less than it used to.
If your answer is "use AI", then why not use AI to not need Pico. This could be maintained for those of us avoiding AI, of course, but we are fewer and further between with each passing day, and likely rolled our own instead of using someone else's framework anyway, so he probably didn't see the point and wanted to spend the time elsewhere.
> brand recognition that shouldn't be throw away
How useful do you think this brand recognition would be in his life? Enough for it to be worth maintaining a project he had presumably moved away from using for his own work & play?
If it is so valuable then maybe someone will make a deal to take over maintainance. Though TBH if this were mine I'd probably prefer to keep the project mine-but-archived than let someone else do what they will with the "brand" thereby diluting what value it might have to me personally. It can just be forked instead, or people can move into one of the already existing forks.
It's a pity that the currently good pure CSS frameworks seem to only have Bootstrap left standing. This leaves me with fewer choices, as someone who uses Ruby On rails / Django and doesn't want to use the new generation of frontend CSS solutions.
I might need a CSS solution that is less React-heavy, one that provides basic components and a user-friendly style system; I just need to include a CSS file (possibly a helper JS file) and then I can make style adjustments in my own application CSS.
> Today, AI can generate lightweight, standalone, accessible HTML with just the CSS it needs, so a Minimal CSS Framework for Semantic HTML matters less than it used to
This argument is basically saying, "Why build anything if AI can do something similar?" Personally, I think there is a great deal of value in building things to a well thought out specification. I don't like this attitude of cognitive surrender.
You guys really need to fix your site to be a demo first. See the nimble css page on how to market yourselves well. Right now your site is not telling me anything about how your library works or looks or how it is actually useful to me and how it solves my problems. The questions I actually have when I visit your site.
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'm not being a design/frontend person, but I can decide if I like or don't like something. Having some default "themes" to say so I can choose from is a large help for me.
I mean with AI you can possibly more easily make decisions on the motor oil and suspension choices of the car you are building... but there may still be people who only want to get an pre-designed car, and only make calls on trim and color maybe.
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 term 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.
This is really sad news to me. I have used Pico several times as an example of good implementation and aesthetics, so the agent could get what I had in mind. In this case, applied human intelligence and good taste had their value when I needed to interact with the LLM. Now that intelligence begins to fade-out.
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, people use it in practice. But it's not being used for the thing you're thinking of.
RGB is fine for specifying a color. I mean, there are issues with RGB colorspaces and whatnot, but if you need to pick the background of a page or the color of text, there's no real reason not to use RGB.
The problem with RGB is that it is really bad at color interpolation. You can't take the average of the red, green, and blue components of two colors and expect a usable color in the middle to come out. Instead, you need to move to a perceptual color space. CIELAB is the old perceptual color space of choice; Oklab is the new perceptual color space of choice.
Color interpolation is needed for things like gradients or information visualization, where you need to say things like "20% of the way between color A and color B".
RGB is also highly unintuitive by itself. Because additive color mixing is unintuitive. There is no way of knowing what RGB mixture corresponds to yellow unless you have memorized it.
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.
> Is using these less-intuitive colour encodings made more practical through the use of CSS variables?
I find it more intuitive: when I want to mix colors, or algorithmically choose colors, only oklch works to give decent results.
Maybe you want to severely darken/lighten a color on a page when the user hovers over it - doing it in RGB or HSL results in a color that does not go with the existing colors. Doing it in OKLCH does.
First of all: Thanks for the work! Used Pico CSS quite a lot in personal and small company projects where a simple site was needed. It was a great help to get things looking good without much effort.
To be honest: I haven't really looked at the CSS that agents have written for me. I'm wondering if CSS frameworks still can play a role in that world as guidelines to get more consistent and maintenable code. On the other hand: agent does it, agent has to fix it.
Still not totally sure where all of this is going.
This saddens me, thank you for Pico. As a backend engineer I used Pico for an internal tool used by dozens of people at my company and it was praised for how intuitive and easy to use it was which was in large part due to how easy it was to build something beautiful with Pico.
Sure sounds like it. CSS-in-JS in general is a horrid idea, having to wait for JS to load in order for the site to render any of its styles. In general I find it strange how actively hostile to the end-user so many of the modern front-end practices are. The very people whose job it is to create interactive experiences for users seem to really want the users to not have a good time.
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.
AI skynet slop is murdering people left and right.
The problem is that the explanation given here makes
only little sense. I am not going to rely or depend
on AI slop, so there is now one less option for me.
I think humans need to stop believing in AI slop as
the new religion for everyone. Some people have a
complete anti-AI policy and pull it through, 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.
> 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.
I don't get any of this hate. oklch makes it really easy to create new tones from a starting point and stuff like anchor positioning also makes it really easy to place absolutely-positioned things. So it's not like those "latest and greatest browser features" are there just to complicate your life, but actually the contrary.
This just seems to me like (1) not wanting to learn new things, (2) a logical fallacy because the conclusion that those changes are to "stay relevant" and not to make the life of any future mantainer easier, and (3) fear of the new (https://en.wikipedia.org/wiki/Neophobia)
If you asked me to pick out bright bold blue (#0000FF) and told me the format was "Lightness Chroma Hue" with valid ranges, I would guess "0.5 1.0 240". Not only is this "not visible on any monitor" by a very large margin but the oklch.com calculator states the spec fallback color is Dell logo blue and not bright at all while browsers will render "vibrant purple".
There's not "120 degrees of red, 120 degrees of green, 120 degrees of blue", so blue is not 240. Actual bright blue is hue 264. The "0-255 RGB" bright blue is 0.452 lightness, and max chroma on a really good monitor is something like 0.33. The lightness mostly makes sense, right? 0.5 is halfway between totally dark and completely washed out.
"Ok, so chroma tops at at 0.33" not so fast. You can crank up the chroma to 0.40 and still get either magenta (where lightness is around 0.74) or green (lightness around 0.78). So now you need to know a valid, nonlinear lightness range for each band of colors, because midpoint blue is different than midpoint red which is different from midpoint green.
From greyscale luminosity calculations and knowing about subpixels and bayer filters, I would've been able to guess that green is the color with the highest chroma, but then there's bright magenta, neck-and-neck. Oh. Until I move the lightness slider down on the web color picker, and then everything (especially peaks) in the chroma channel shifts around dramatically... So much for intuition.
While OKLCH makes it really convenient to select colors with properties you like along a gradient, the nonlinearity means either memorizing a bunch of base colors, using a color picker, or converting from a system that is "actually" intuitive. I can't really look at a trio of OKLCH numbers and predict the output color like I'd be able to with RGB, although this is mindful that RGB is also not linear (for the exact opposite reason as OKLCH) and I can only do that from decades of experience.
I'll concede that magenta and bright green and bold blue don't really have a place on the world wide web other than in a company logo, so these are outliers. Still, the OKLCH format is not what I'd call intuitive to a total beginner.
(Also, I'd very much not like to implement OKLCH calculations on a microcontroller until lighting companies start selling OKLCH LEDs.)
Thank you for putting in words why I struggle with OKLCH. I found it non-intuitive to learn as a human being despite its "gradient" advantage. I still stick to HSL. (Though I wish web had adopted HSB)
bro what?
> So it's not like those "latest and greatest browser features" are there just to complicate your life, but actually the contrary.
What justification do you have to adopt and replace this with existing solutions with such urgency? Have you researched its compatibility? Are you providing any fallback?
This just seem to like 1) you are not applying your mind why you want this, 2) faulty premise that it makes it easier, because in reality your software never reaches a point of maturity, where its just "done", and 3) shiny object syndrome (https://en.wikipedia.org/wiki/Shiny_object_syndrome)
I think you two should take this rather pointed dispute outside and resolve it with a duel (https://en.wikipedia.org/wiki/Duel)
Standardization is valuable.
[dead]
I'm pretty sure I'd hate Tailwind, but please leave OKLCH alone. It is actually ok (as opposed to RGB and HSL which very much aren't ok).
Respectfully it's up to the maintainer who decides where they think it shoudl go.
After I read the same I thought, ok, that's what _they_ wanted to do.
Me? I'd love to see what could be rewritten to be 100% future proofed for as many years as possible. But see what that did? I have to share, and see if anyone else already thought of this (I doubt I'm the first ever to have this thought), and maybe, I'll be lucky enough to benefit from someone exploring it already, before I decide to put on a jedi robe and wave my hands to use the force to move AI around.
How can you hate Oklch?
This is a strange take, sorry, OKLCH is simply better and it's not that complicated to understand?
OKLCH is as you say unambiguously better and IMO easier to understand than RGB, where choosing relative adaptations of colour is basically pretty fraught.
Alas, in terms of the software people use to mock up designs, very few desktop apps support it. HSL is, for now, the more practical option.
Perceptual colour spaces are emphatically not “simply better”. They’re better for most colour mixing (which is of more limited application than you may think) and for some sorts of intuitions, but their shape is far more complex, not mapping to the actual screen gamut in any predictable way, making them highly obnoxious for colour selection, because it’s super easy to fall out-of-gamut without realising it (and I don’t know of any tooling that draws your attention to when that happens) so that its entire purpose is compromised, and they’re downright atrocious at handling vivid (near edge-of-gamut) colours.
Take bright yellows as one of the worst examples. Basically the only thing you can do with them is reduce the chroma: any other change will take you out of gamut. As the most extreme case, #ff0 is approximately oklch(0.968 0.211 109.77), and the following minuscule modifications will take it out of gamut: L + 0.0002, L − 0.0001, C + 0.0002, H − 0.009 or H + 0.025.
This is why the creator massaged them into a cube/cylinder: https://bottosson.github.io/posts/colorpicker/, Okhsv and Okhsl. Those are much closer to being uniformly superior to sRGB.
Fashion and CV driven development, used to sell conference talks, books and agency work for "upgrades".
> Why? Why? Why? I hate how everyone seems convinced they need to adopt the latest and greatest browser features just to stay relevant.
Presumably we can deprecate the broken shit if we can get people to buy into software upgrades.
Are RGB and HSL color models all broken and useless? Yes, I know their limitations. But of all graphical software I use daily. only GIMP supports LCh, and using it is pretty unintuitive.
I see how position-anchor and stuff are coll for complex layouts, but they have poor support on low-power mobile browsers, and, frankly, are not that useful for a minimalistic CSS framework. If you want complicated layouts with non-obvious anchoring rules, you're not the target audience.
Cascade layers are very useful for complex designs with many independently added stylesheets. They would be great to have. OTOH again, if you need this level of complexity, you're likely not the target audience of a pico-sized CSS framework.
I would say that a minimalist framework should make judicious use of CSS3 features, and not try to be excessively clever. In reliable engineering, being smart often means avoiding being clever.
Look all I can say is now that we have LLMs, you'd have to put a gun to my head to target the browser. Worst application platform imaginable. Somehow it's also become a pretty bad document browser.
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/
For Blades CSS, we also set up a dedicated page outlining key details and fixes made in underlying Pico fork: https://blades.dev/css/pico/
I was a big fan of pico! Such an inspiration. I created https://github.com/lekoala/actual-css as an attempt to get something modern yet as compatible as possible with older browsers (still ended up using popover because it's such a welcome addition to modern css). I'm still not sure modern css frameworks need to use layers (it breaks on older browsers) or anchor positioning (minimal js does the job, sometimes even better, and again: more compatible).
All of them failed my ten second evaluation. It's amazing how many mediocre CSS frameworks that are out there.
What's your ten second evaluation?
What do you think of https://starter.bryanhogan.com/ then?
Useless - https://ibb.co/h1sRtYKF
I don't see that on my Android phone with Chrome. Looks good for me.
What the hell browser is that?
It's broken in the exact same way in the last version of Vivaldi that works on Windows <10.
From a quick look at the second horizontal strip that starts "what is this?", and without wasting time doing too much digging, it appears to be ultimately caused by using a grid layout for a heading followed by a few paragraphs, all of which fill the available (constrained) width, which amounts to one of the absolute simplest layouts possible in CSS - block. Last time I saw something similar, albeit with flexbox not grid, it was from a junior developer who appeared to have only learned flexbox and nothing else.
As a quick semi-fix, just disabling grid-template-columns on .base-layout is enough to fix almost everything except the constrained width.
Sounds like that older Vivaldi version does not support CSS nesting. I looked into it. I'm assuming you are using Vivaldi 5.6 which uses Chromium 108, native CSS nesting became supported in Chromium 112.
The layout approach is based on this Kevin Powell video: https://m.youtube.com/watch?v=c13gpBrnGEw
It uses CSS Grid to create a centered, width-constrained content area while allowing individual elements to break out of it or span the full viewport width. This provides a flexible, consistent layout without the need for additional wrapper elements in the HTML.
CSS nesting has had full browser support for more than 3 years now, I recommend updating. I'll also add fallback for older browsers, but the Grid layout itself isn't the issue.
> Vivaldi 5.6 which uses Chromium 108
Yes, that's right. I thought I'd try it in that older browser that I still happen to have installed, as the user above didn't immediately let us know what that mobile browser was. It may or may not help by at least giving you a browser version you can use to test. As I mentioned somewhere else, it makes sense to use some sort of older browser as a proxy for older browsers in general, when testing.
Developers are always looking for new ways to do what we've always done, often using more technically complicated ways to recreate the simplest things. It's fun from the puzzle-solving point of view, but your choice of earliest browsers you want to support depends on your user base.
Yes, but what browser is it?
Despite its idiotic naming, I still use PureCSS[0]. Not sure why they keep maintaining it. I don't mind, nothing ever seems to change anyway.
How's your ten second evaluation of it?
[0]: https://pure-css.github.io/
I'm using it but it's such a pain in the arse to find anything else online about it.
It's one of the reasons I'm planning on moving stuff over to Pico.
Or now, I guess, just writing some CSS from scratch, which I hate.
I built https://purecss.com (not pure-css.github.io), maybe you'd find the site helpful? Currently it's 77 CSS patterns and another ~20 coming in the next few weeks. Each have a demo and the code underneath. Check it out and let me know if there's something you can think of that you'd like to see there. Happy CSS'ing!
So actually "pure CSS", and not the "pure.css" library that's so hard to search for? A lot of that looks pretty good!
Yea, exactly and thanks! I love making CSS things that were previously only possible with JavaScript. Carouses, accordions, toggle switches, etc. I love how powerful CSS has become over the last few years!
Yes it is a pain. But the whole thing is like two pages, so I^H my LLM just reads it. I used to read it. It was ok readable (and I'm not very good at CSS).
Whats the first thing in a CSS framework that you notice and makes you say "nah"?
CSS frameworks are like children, almost everyone can make one.
None of them work on older browser - https://ibb.co/album/3kJP50
Ios 13.6 in my case, which was released just 6 yrs ago, 2020. For some context, flexbox gap was added in ios14.1, released in 2021. So iOS 13.6 was still usable atleast couple of years beyond that. So such frameworks utterly failing on such browsers is hilarious, given that they market themselves as minimal.
People keep forgetting that css3 was announced in 1999. And adoption roughly started from 2010. The css3 of that time is not the same as css3 you get to see in latest browsers. These minimal css frameworks are really useless if you don’t know what css3 features you are writing and who you are targeting.
And, I Haven’t even tested those in less capable browsers like dillo or netsurf, but I doubt they will even work there.
If you start looking into browser market share, you will quickly realise that there are millions of worldwide users who can’t use the web normally.
> So such frameworks utterly failing on such browsers is hilarious, given that they market themselves as minimal.
Minimal is an entirely different property to backwards compatibility.
When you say something is minimal, you are implying that what little you provide will also work. Which in this case is clearly not.
motherfuckingwebsite.com is more minimal and usable than these frameworks.
> When you say something is minimal, you are implying that what little you provide will also work.
No you do not. You just saying it’s got very little code and/or very few features.
Support for older browsers might not be one of those features. Which means this minimal frameworks isn’t suited for the kind of projects where that kind of compatibility is a concern.
If you look outside of CSS (and particularly web development as a whole) you’ll find a plethora of minimal frameworks that intentionally make compatibility trade offs.
> Which in this case is clearly [does not work].
That’s a gross exaggeration and you know it.
As you're mainly complaining about CSS layout features being used here:
For a long time we were forced to use the ugliest hacks imaginable to get to the nice (responsive, design-minimalist(!)) layouts we wanted, because CSS layout tools were utter archaic bs, for years on end, because browsers iterated so slowly.
Then things started speeding up, and we're getting to make better websites (and apps!) that are way easier to design (with the correct design theory equivalents), implenent (with less code) and easier to maintain (i.e., understand). And you're not missing out if you just keep your browser up to date.
I know it sucks if you're on an unsupported device that doesn't get any updates, fair.
But let's face it: 99% of the population is better off security-wise when we're not enabling them to run unpatched devices forever.
Security updates have nothing to do with level of support for css3 modules.
Much of the issues of layout were already solved more than 12 yrs back, ie when css3 became mainstream.
The issue is devs are unaware about different levels of css3 or just plain ignorant about it.
Are you aware about the different levels of css3? Are you even aware there are levels to css3? Why are these frameworks not listing them and simply saying that they comply with web standards? Which specific web standards do they comply?
Any new css3 feature should have a fallback if they say they comply to web standards, which these frameworks don’t add.
Basically you want to adopt latest w3c guideline but completely ignore wcag guidelines on accessibility - https://www.thewcag.com/principles/robust
Why should some population forced to suffer because of your ignorance. I am sorry if I am blunt, but your comment about polarising users is rude.
Which comes back to my main point, Devs are simply not educating themselves about the fundamentals of web design.
I think its fine to target compatability with 99.9% on people with updated devices and not some random old 2020 safafi build
To be fair on this particular point, talking about iOS Safari before version 14 isn't "some random old build". It depends on your own users, but I saw plenty of 6-year-old iPhone user agents in the web logs when dealing with a doctor's surgeries app.
Even though I provided a direct link to wcag principles and guidelines, you still are too lazy to read.
> None of them work on older browser
There are older browsers which still get security patches?
They don’t unfortunately but it is a good reference for me to check how it looks on previous versions of browsers and less powerful devices. That way I know if the UI or UX needs improvement.
ios updates unfortunately ties everything to a single batch. Unlike android. I have an older blackberry, that still gets latest app updates.
What is even hilarious is ads render with pixel perfection on older devices. So for some reason, ad networks care about browser compatibility than devs putting the same ads on their incompatible website.
Exactly. Ad creators know that the purpose of what they're building is more important than their personal dev experience of using shiny new tools. It's such a shame the fashion is the other way for so many web developers, largely the younger and less experienced ones.
And yes, it makes sense to use one particular old browser as a general proxy for older browsers in general, so people shouldn't get hung up on the particular version of Safari you happened to mention.
> It's such a shame the fashion is the other way for so many web developers, largely the younger and less experienced ones.
I don’t care about what’s trendy, but using outdated, insecure browsers to surf the web is just plain stupid. Even more, expecting developers to waste time working around all the bugs in those old browsers is just insane. I do the opposite: as soon as a browser reaches EOL I drop the support. Don't encourage lazy admins and bad habits.
It's a shame such an arrogant attitude exists, to call everyone who can't afford to replace their iPhone with a newer model "stupid". And developers really should know better than to fall for the marketing nonsense that anything more than 5 minutes old is "insecure".
> expecting developers to waste time working around all the bugs in those old browsers is just insane
What bugs? The ancestor posts are talking about frameworks immediately using features that were just added to browsers - i.e. more recently than those older versions. Nothing at all to do with bugs. Can you help us to see what you've misunderstood here? Perhaps not dismissing users as "stupid", developers as "insane", and admins (?) as "lazy", would be a good starting point.
> can't afford ... iPhone
Seems to be a bad decision from the beginning.
> And developers really should know better than to fall for the marketing nonsense that anything more than 5 minutes old is "insecure".
Where have you been the last decades? Pick an arbitrary browser and go through their CVE list, e.g.: https://app.opencve.io/cve/?product=safari&vendor=apple
> What bugs?
I guess at that point I have to assume you have no idea about front-end development. Otherwise you would know what a pain in the ass old browsers with their inconsistencies are (e.g. remember the struggle with the early flexbox implementations?).
> Seems to be a bad decision from the beginning
I don't disagree! But at the same time, part of our job as web developers involves acknowledging the reality of what our users actually do.
What do early flexbox implementations (something like 12-15 years ago?) have to do with anything? We're not talking about browsers as old as that! They weren't even bugs, they were early implementations of early versions of the standard, so who exactly is the one with no idea here? That level of browser inconsistencies is long gone.
Those of us with years of experience of building user-centric front-ends are not the ones who jump to use new browser features too quickly.
I won't be continuing this conversation, due to the general arrogance and condescension displayed in your posts - following "stupid", "insane" and "lazy" with "bad decision", "where have you been" and "you have no idea".
[flagged]
[dead]
I really enjoyed using Pico CSS, but I understand the choice.
Thank you Lucas Larroche for building Pico CSS and sharing it with us.
With AI he could have made the updates to "stay relevant" as he called it. That seems easier than ever. PicoCSS has brand recognition that shouldn't be throw away.
"With AI" is answered in the first sentence:
> Today, AI can generate lightweight, standalone, accessible HTML with just the CSS it needs, so a Minimal CSS Framework for Semantic HTML matters less than it used to.
If your answer is "use AI", then why not use AI to not need Pico. This could be maintained for those of us avoiding AI, of course, but we are fewer and further between with each passing day, and likely rolled our own instead of using someone else's framework anyway, so he probably didn't see the point and wanted to spend the time elsewhere.
> brand recognition that shouldn't be throw away
How useful do you think this brand recognition would be in his life? Enough for it to be worth maintaining a project he had presumably moved away from using for his own work & play?
If it is so valuable then maybe someone will make a deal to take over maintainance. Though TBH if this were mine I'd probably prefer to keep the project mine-but-archived than let someone else do what they will with the "brand" thereby diluting what value it might have to me personally. It can just be forked instead, or people can move into one of the already existing forks.
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.
this
100%
It's a pity that the currently good pure CSS frameworks seem to only have Bootstrap left standing. This leaves me with fewer choices, as someone who uses Ruby On rails / Django and doesn't want to use the new generation of frontend CSS solutions.
I might need a CSS solution that is less React-heavy, one that provides basic components and a user-friendly style system; I just need to include a CSS file (possibly a helper JS file) and then I can make style adjustments in my own application CSS.
Do you have any recommendations?
> Today, AI can generate lightweight, standalone, accessible HTML with just the CSS it needs, so a Minimal CSS Framework for Semantic HTML matters less than it used to
This argument is basically saying, "Why build anything if AI can do something similar?" Personally, I think there is a great deal of value in building things to a well thought out specification. I don't like this attitude of cognitive surrender.
https://github.com/anyblades/blades seems to be a continuation in the same spirit
Thanks for sharing! Same spirit, same underlying code.
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/
You guys really need to fix your site to be a demo first. See the nimble css page on how to market yourselves well. Right now your site is not telling me anything about how your library works or looks or how it is actually useful to me and how it solves my problems. The questions I actually have when I visit your site.
[dead]
Im working on PicoCSS on the its repo on GitHub
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
Bourbon is no longer maintained.
Guide for replacing its features : https://thoughtbot.com/blog/you-might-not-need-bourbon
I'm not being a design/frontend person, but I can decide if I like or don't like something. Having some default "themes" to say so I can choose from is a large help for me.
I mean with AI you can possibly more easily make decisions on the motor oil and suspension choices of the car you are building... but there may still be people who only want to get an pre-designed car, and only make calls on trim and color maybe.
[dead]
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 term 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.
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.
What would you choose?
tailwind!
ew. at least use daisyui
This is really sad news to me. I have used Pico several times as an example of good implementation and aesthetics, so the agent could get what I had in mind. In this case, applied human intelligence and good taste had their value when I needed to interact with the LLM. Now that intelligence begins to fade-out.
It continues to be a good example of those things even if it's not maintained
I love plain old Vanilla CSS. Pre-processor-free for a couple years now and don't miss anything.
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, people use it in practice. But it's not being used for the thing you're thinking of.
RGB is fine for specifying a color. I mean, there are issues with RGB colorspaces and whatnot, but if you need to pick the background of a page or the color of text, there's no real reason not to use RGB.
The problem with RGB is that it is really bad at color interpolation. You can't take the average of the red, green, and blue components of two colors and expect a usable color in the middle to come out. Instead, you need to move to a perceptual color space. CIELAB is the old perceptual color space of choice; Oklab is the new perceptual color space of choice.
Color interpolation is needed for things like gradients or information visualization, where you need to say things like "20% of the way between color A and color B".
RGB is also highly unintuitive by itself. Because additive color mixing is unintuitive. There is no way of knowing what RGB mixture corresponds to yellow unless you have memorized it.
> Do people actually use this?
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.
[1]: https://joeldueck.com
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.
Website https://colorcolor.in
Source https://github.com/saneef/color-color
This is my fave article on the subject:
https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...
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.
> Is using these less-intuitive colour encodings made more practical through the use of CSS variables?
I find it more intuitive: when I want to mix colors, or algorithmically choose colors, only oklch works to give decent results.
Maybe you want to severely darken/lighten a color on a page when the user hovers over it - doing it in RGB or HSL results in a color that does not go with the existing colors. Doing it in OKLCH does.
I love OKLCH. Awkward to say, beautiful to look at.
First of all: Thanks for the work! Used Pico CSS quite a lot in personal and small company projects where a simple site was needed. It was a great help to get things looking good without much effort.
To be honest: I haven't really looked at the CSS that agents have written for me. I'm wondering if CSS frameworks still can play a role in that world as guidelines to get more consistent and maintenable code. On the other hand: agent does it, agent has to fix it.
Still not totally sure where all of this is going.
This saddens me, thank you for Pico. As a backend engineer I used Pico for an internal tool used by dozens of people at my company and it was praised for how intuitive and easy to use it was which was in large part due to how easy it was to build something beautiful with Pico.
Anybody uses https://unocss.dev/? I was thinking about moving to it from pico.
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.
Is zero-runtime CSS-in-JS an oxymoron?
Sure sounds like it. CSS-in-JS in general is a horrid idea, having to wait for JS to load in order for the site to render any of its styles. In general I find it strange how actively hostile to the end-user so many of the modern front-end practices are. The very people whose job it is to create interactive experiences for users seem to really want the users to not have a good time.
It's not how zero-runtime CSS-in-JS frameworks work. Users are just served pure HTML and CSS.
CSS is typed in JS, but it is transpiled at compile time to pure CSS. So truly zero runtime.
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.
What a tragedy.
AI skynet slop is murdering people left and right.
The problem is that the explanation given here makes only little sense. I am not going to rely or depend on AI slop, so there is now one less option for me.
I think humans need to stop believing in AI slop as the new religion for everyone. Some people have a complete anti-AI policy and pull it through, too.
Thank you for the training data
I miss 960px grid systems…
Im on it -> @srvrX0r
> 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?
We do: https://github.com/anyblades/blades
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)
Have you guys posted about blades in the FastHTML discord channel (I think?)
Yes, and the FastHTML team was very collaborative in switching to our underlying Pico fork (Blades core)
But why? Is it not relevant anymore? It's as useful and capable as it was years ago
[dead]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[dead]
[dead]
Hmm. I use pico. They could use an agent to modernize it!
Yeah, but why? Writing code for agents to use isn't fun, and buying tokens for it is a waste of money.