[aniforprez]

Not entirely convinced about their graphs where they "improve" over tailwind with just HTML size and "number of class names". Why do these matter exactly? You're basically removing the number of classes in the HTML and adding the CSS anyways so how much are you really saving here?

I don't mind the existence of this library obviously but condensing into tiny abbreviated classes seems like the antithesis of tailwind but maybe it's for folks who can't or don't want to define a base button component every time and want a jumping off point. In that case I'd much rather use shadcn or something based on react-aria that gives me solid primitives that I can extend with tailwind classes passed to it in specific instances

[seaal]

I imagine you're using most elements more than once in the HTML so the class names would be repeated X number of times.

[mpeg]

Repeated strings like that should compress pretty well with gzip, which is one of the core ideas behind atomic css performance, alongside the difficulty to remove dead css – with vanilla html/css your css grows unconstrained

With atomic css, your css stays a constant size, your html will be bigger but is easier to manage as you naturally add/remove html as page content changes, plus compression should be pretty efficient.

I've had to manage legacy frontend codebases with tens of thousands of lines of mostly unused css that were not easy to remove as they might have been used somewhere, that's what led me to start using atomic css.

I don't really love tailwind, but I appreciate it has become ubiquitous so I do use it, and the ideas behind atomic css are solid when you maintain a large frontend codebase. It has also led to the rise of self-contained components as opposed to libraries (shadcn and all the others) which I couldn't be happier about.