Sounds like a lot of the objections I have. To be fair a lot of my other objections were answered in this excellent post In Defense of Utility-First CSS. I'm not sure where I stand now. I know I wish Tailwind had more ability to be able to convert from Tailwind to something else. It's a big reason I didn't buy Tailwind UI even though I bought the Refactoring UI book. I work in devrel where I will often make demo apps but I don't want a lot of stuff in them besides what I'm trying to demonstrate. I don't want to set up a bundler either and Tailwind CSS doesn't work great with a CDN/just as a simple stylesheet because it's HUGE.
For now I've been using a lot of "classless" CSS "frameworks" like Sakura.css.
Also it makes me glad I'm not a front end dev anymore 😂
Founder and lead developer at Whitefusion, a boutique web studio located in Portland, Oregon. On the core team of Bridgetown, a static site generator. Proud Rubyist!
The link there is a good overview of the "pro" side. I think what's really changed the game though is the rise of CSS variables, thereby rendering the objection to inline styles moot. For example, in the section Inline styles allow you to do anything you want. it shows putting font sizes and padding and such in a style= attribute. Everything's hard-coded. That's bad. But now it doesn't need to be hard-coded! You can put style="font-size: --var(size-lg)" or style="color: --var(color-primary-500)" etc. And of course it scales up to regular stylesheets or even CSS-in-JS techniques.
So, in a sense, you can have your utility CSS cake and eat BEM too (or some such methodology), without having to define a thousand utility class names. That's how I like to look at it anyway.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sounds like a lot of the objections I have. To be fair a lot of my other objections were answered in this excellent post In Defense of Utility-First CSS. I'm not sure where I stand now. I know I wish Tailwind had more ability to be able to convert from Tailwind to something else. It's a big reason I didn't buy Tailwind UI even though I bought the Refactoring UI book. I work in devrel where I will often make demo apps but I don't want a lot of stuff in them besides what I'm trying to demonstrate. I don't want to set up a bundler either and Tailwind CSS doesn't work great with a CDN/just as a simple stylesheet because it's HUGE.
For now I've been using a lot of "classless" CSS "frameworks" like Sakura.css.
Also it makes me glad I'm not a front end dev anymore 😂
The link there is a good overview of the "pro" side. I think what's really changed the game though is the rise of CSS variables, thereby rendering the objection to inline styles moot. For example, in the section Inline styles allow you to do anything you want. it shows putting font sizes and padding and such in a
style=attribute. Everything's hard-coded. That's bad. But now it doesn't need to be hard-coded! You can putstyle="font-size: --var(size-lg)"orstyle="color: --var(color-primary-500)"etc. And of course it scales up to regular stylesheets or even CSS-in-JS techniques.So, in a sense, you can have your utility CSS cake and eat BEM too (or some such methodology), without having to define a thousand utility class names. That's how I like to look at it anyway.