Maybe you are making my point? If tailwind was "just utility classes", fine. But what business would it be there if they just published a bunch of CSS files with their styles? With modern CSS, what problem are they really solving now ?
As someone who made a competing product along these lines (that got no attention or traction): Tailwind gives CSS a "place" in the codebase. It benefits orgs, not necessarily apps. I didn't get it at first either. But it's very useful to the people to whom it's useful.
> I didn't get it at first either.
maybe you got it wrong? CSS already have its place and work great as .css files
Sure? I don’t see how that’s an argument for CSS “being advanced enough” - SASS ain’t CSS. I like SASS (I wrote a lisp in SASS in 2011 lol) and that’s actually how I think about Tailwind utilities - it’s just using SASS mixins directly in your HTML. I would rather use Tailwind because it will take 1/3 the levels of abstraction, 1/4 the keystrokes and 1/2 the files to do the same job to: 1. Pick a class name (myclass)…
> I don’t see how that’s an argument for CSS “being advanced enough” That's a separate argument. I hear mostly two justifications for tailwind: 1. It is (or used to be) hard to do things in CSS like variables, calculated properties, themes, scoped rules / namespacing. (Pre/Post) Processors are going to be required anyway, so we might as well use Tailwind 2. It gives frontend developers and designers a common language…
I agree neither of those seem like good reasons to pick tailwind.
My take is that it removes needless indirection in any codebase that already has “components” - react/vue/solid/etc, template partials, functions that return html strings, whatever. See comment here: https://news.ycombinator.com/item?id=42804831
For that reason, plus it’s concision, I find it more productive use of time compared to css-in-separate-file.
If you don’t have components for separating semantics from presentation, then tailwind is less a good fit.
The problem is that with bootstrap I have card, table, etc. With tailwind I have an unreadable alpabet soup when I am not a designer but a developer and am not familiar with tailwind.
This is the big one for me. In any big enough or unfamiliar frontend project, my go-to way to explore the codebase is to launch the front-end, and use the inspector to check the elements, and then search-back in the codebase the relevant classes to see what page/component display that, and how does it fetches the data. If there is only an alphabet soup, I no longer have a simple set of classes I can grep the codebase…
Use the component library’s inspector/devtools to identify components. Eg in a React app, look at the React component tree rather than the DOM tree
There was a time when BEM ruled (and scarred) the world. But names aren't a problem if you abandon the C in CSS and scope all styles to component.
What I don't understand is why BEM is scarring. If you're talking about the reason or timing something looks different, you must have named it in that conversation. Just use that name. "When the menu is wide, the items' icons and text should be visible. When it's skinny, only the icons should be visible. This button toggles between them." .menu {} .menu--skinny {} .menu--wide {} .menu__icon {} .menu__text {}
Or I could just express this in code once - in the spot where I attach the class names to the HTML - instead of attaching class names, just attach styles.
I think it’s because now your entire component is contained in a single file. No more separately messing around with CSS. The styles are right there on the element they apply to without having to cross reference anything. You could do this with just the css attribute, but that has the issue that everyone has always been taught it is wrong to do that, and a list of strings that contain a bunch of utility is easier tha…
> You could do this with just the css attribute, but that has the issue that everyone has always been taught it is wrong to do that But why is it wrong to use the style attribute? What makes using tailwind to do the same thing "not wrong"? Also this https://tailwindcss.com/docs/hover-focus-and-other-states#us... and https://tailwindcss.com/docs/hover-focus-and-other-states#st... look like reinventing the Cascading of…
Tailwind I use for hobby projects but we’re still sticking with style={{…}} at Notion. Since the app launched there’s been many generations of CSS-for-React (Airbnb Aphrodite era, styled-components/Emotion era, styled-jsx/linaria era, CSS modules era, Tailwind era) come up, get hype, and then thrown in the trash heap. Probably the best move for us would be an optimizing compiler for style={{…}} or our useStyles hook.
In v3, one can use `blocklist` in the config to eliminate false-positives, but with the config file gone, this seems no longer possible, so I won't be upgrading. In one project, roughly 75% of the detections were false-positives, unnecessarily bloating the CSS.
You can disable automatic detection and manually configure which files to look at: https://tailwindcss.com/docs/detecting-classes-in-source-fil...
This seems like the best path forward if you're using v4.
Man their very playground at https://play.tailwindcss.com/ gives this unreadable crap (sorry for swearing) for the very first `div` on the first line: relative grid min-h-screen grid-cols-[1fr_2.5rem_auto_2.5rem_1fr] grid-rows-[1fr_1px_auto_1px_1fr] bg-white [--pattern-fg:var(--color-gray-950)]/5 dark:bg-gray-950 dark:[--pattern-fg:var(--color-white)]/10 How can anyone prefer this gobbledygook over a nice CSS class d…
Because your not thinking of styles practically. You don't review style declarations, you review the rendered page/component. You see with your eyes that a component has the wrong border color, and AFTER THAT you go to your component code, find the border color declaration (if any), and update it/add it. Sometimes you'll even inspect the element in browser, and find the faulty class directly, making it even easier to…
Exactly, it's not like a novel where you are trying to read the entire thing. And it's an advantage because it is easier to parse. If I'm trying to change the color on that element, I have a very good idea what controls that. As opposed to something like "card_wrapper card_wrapper--striped". That certainly looks better, but if I'm just there to change the grid, now it's a more complicated change. In Tailwind, I can just look, see "grid-cols-[1fr_2.5rem_auto_2.5rem_1fr]" and know that not only that's where to change it, but that I can also change the classname there without worrying about a regression in some other element somewhere else. Whereas with "card_wrapper card_wrapper--striped", well what controls the grid? I have to look in another file, and I also have to be concerned about every other place those classes are used. (Or I have to add new one-off classnames, at which point the complaint about long classnames holds less weight.)
But the Tailwind configuration provides a solid structure for your own though.
just like CSS
Not really the same, although I realize it can seem that way.
If you go low level enough everything technically fits that bill, it’s just a matter of how much work you have do to put the structure in place and what the burden is for other people to learn it.
It’s akin to raw Perl vs Ruby on Rails. You can do it that way, nothing is stopping you…but there are compelling reasons not to.