Pico CSS stellt den Betrieb ein – weil KI das schlanke Framework überflüssig macht
Pico CSS is no longer maintained
Mit Version 2.1.1 endet die Entwicklung von Pico CSS. Der Maintainer begründet den Schritt damit, dass KI heute leichtgewichtiges, barrierefreies HTML samt passendem CSS erzeugen kann, wodurch ein minimales Framework für semantisches HTML an Bedeutung verliert. Eine Weiterentwicklung hätte einen kompletten Neuschrieb erfordert. Die Repositories sind archiviert, npm, jsDelivr und die Website bleiben online, und unter MIT-Lizenz darf jeder das Projekt forken.
Heute kann KI leichtgewichtiges, eigenständiges, barrierefreies HTML mit genau dem CSS erzeugen, das es braucht – ein minimales CSS-Framework für semantisches HTML ist deshalb weniger wichtig als früher.
- shubhamjain
> Um relevant zu bleiben, müsste Pico CSS komplett neu geschrieben werden: reines modernes CSS statt Sass, aufgebaut auf Features, die es heute nicht nutzt (OKLCH-Farben, Cascade Layers, Popover, Anchor Positioning) mit Fallbacks für ältere Browser
Warum? Warum? Warum? Ich hasse es, wie alle überzeugt zu sein scheinen, dass sie die neuesten und tollsten Browser-Features übernehmen müssen, nur um relevant zu bleiben. Ich hasse oklch und ich hasse es, dass Tailwind es populär gemacht hat. Es ist mir egal, wie wissenschaftlich genau es die menschliche Farbwahrnehmung darstellt. Es ist eine Qual, ein neues Farbsystem zu verstehen und zu lernen, es anzupassen, besonders wenn HSL/RGB einfach gut funktioniert haben.
- sphars
Einige neuere Alternativen/Nachfolger/Forks, die in dieselbe Kerbe wie Pico schlagen
- 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/
- eterps
Ich habe Pico CSS wirklich gerne benutzt, aber ich verstehe die Entscheidung.
Danke Lucas Larroche für das Erstellen von Pico CSS und das Teilen mit uns.
- Brajeshwar
Zuerst gestehe ich, dass ich in meinem frühen Entwicklerleben ziemlich viele CSS-Frameworks und Design-Systeme gebaut habe. Das hier wird also eher eine persönliche Erfahrung.
Seit Coding-Assistant-LLMs ziemlich gut geworden sind (2025-Q4 – 2026-Q1), habe ich das Gefühl, dass es wenig Sinn macht, weiterhin vordefinierte CSS-Frameworks zu verwenden, die 'alles haben'. Natürlich ist es immer noch okay, wenn das allgemeine Team sich für eines entscheidet, und sie sind okay (wie die Tailwinds, MUI der Frontend-Welt).
Ich habe Foundation[1] und Bourbon[2] ausgiebig genutzt. Hauptsächlich, weil ich sie herunterbrechen und nur das nehmen kann, was das Projekt braucht, und es innerhalb eines niedrigen CSS-Budgets für jedes Projekt halten kann.
In diesem Sinne habe ich in den über 10 Projekten, die für einige der größten Marken der Welt gestartet wurden, einfach das CSS-Framework, die Design-Systeme, Design-Token definiert, mit Raum für Erweiterung, während das Projekt wächst. Claude Code ist derzeit mein Tool der Wahl und ich lasse es einfach über Nacht laufen, passe an, während das Projekt aufgebaut wird, und schließlich dauert es weniger als eine Woche, um ein komplettes CSS-Framework in reinem CSS und JavaScript, wo es mit dem breiteren Frontend kommunizieren muss, zu haben.
- suhlig
Vielen Dank für deine Leitung über die Jahre. Und Anerkennung dafür, dass du es nicht einfach verrotten lässt, sondern klar kommunizierst und es verantwortungsvoll schließt.