I just can't fathom how someone can look at this and think "yeahhhh thats some good clean code". How did tailwind get so popular? Learn plain CSS. It's really good now
This is one of the least elegant ways to scope CSS though.. you may as well just write inline CSS
I like BEM personally. "navbar__item" scopes the styling to the nav item
> Once you're well familiar with your toolset, you know what to reach for to quickly reach a desired end state
This also applies to plain CSS, doesn't it?
The big value add that Tailwind brought isn't their utility classes IMO - it's their philosophy around having a design system of consistent coloring and spacing. I actually borrowed that for my own projects. It taught me to be a lot more diligent about specifying the system upfront. Put it in CSS variables and re-use those
You can’t use inline css it’s not at all the same.
Inline css
1. Can’t use media queries (responsive design).
2. Gets you to specificity hell - you loose ability to cascade.
3. Does not follow any system or reuse of values.
4. Values can’t be centrally changed. Utility clases are still classes - when you change class value it changes everywhere where the class is used.
5. Its verbose. Utility classes can have multiple css rules.
Conceptually it might seem that inline css is similar but thats just feeling. Functional css (utility classes) are about composing classes with simpler (one purpose) behaviour together to create complex behaviour.
When people complain about CSS being hard I'm not sure what parts of it really? It's rarely explained further too.
As someone that did a lot of CSS like 15 years ago when fullstack was the norm, then just sporadically for various non-public tooling, is that yes, the old ways of trying to position things really sucked and had a lot of hacks and some of those trail-n-error "how-does-this-change-the-elements-position" seems to still apply, but are much rarer now with grids/flex etc. But the structure of CSS itself is very straight-forward to me and has almost always been?
Is what's really going on that when people are trying to use vanilla CSS they go overboard with keeping CSS DRY? Which ofc ends up with an interdependent mess that's becomes increasingly harder to change. Just stop that? Start namespacing and copy pasting? CSS doesn't need to be compact.
The hard part isn't just placing the correct styles, that is trivially learnable, it comes in when you have multiple people touching the same code, or even in small teams with a large enough project. In a large enough project, and IME that "large enough" point gets hit very quickly, things become messy and it becomes difficult to figure out why something is rendering in the way it is.
Every non-tailwind project I've ever worked on inevitably devolved into a mess where you have 50 billion CSS files scattered all over the place, many containing classes that contradict and override other existing classes, often in completely unclear ways as it's hard to know in which order things will get compiled ultimately. As time passes, you'll see BEM done in various ways, you'll see cursed SCSS functions that generate styles dynamicslly, you'll see a bunch of !importants, and eventually you end up in a state where making a change to a legacy page becomes an exercise in dodging specificity and ordering minefields.
Meanwhile with Tailwind, everything is localized to the element it's affecting, and very importantly the entire team has a "standard library" of properties and patterns they can pull from, so you don't end up with people in different teams naming similar UI patterns differently, and you straight up never have to think of specificity ever again (which in my view is a boon, despite what CSS purists might say). Yes, the HTML is more verbose, but this is just such a non-issue after the first 5 minutes of discomfort, plus all the other benefits.
Hot take, but the Cascading part of CSS has proven itself to be a massive drawback, and not a benefit. Tailwind obviates that completely.
This sounds like it agrees with my point of going overboard with DRY? But this is true for pretty much all languages. When people go overboard with abstractions it usually ends up bad over time and changes, as in your example as well, starts becoming a dredge. But this is solved by experience and better practices, not throwing out the baby with the bath water. Tailwind seems strangely defeatist to me - going from one extreme to another.
1. Aren't there good tools that can list all the elements a style would be applied to so that you can pick and change only the ones affecting the element you need?
Tailwind goes into crazy extreme so people can copy paste whole complex components and they work. That’s why you can dunk on these verbose examples.
This is not how custom functional css codebase looks. In custom projects you change the system/configuration to fit the project. You create your own utilities for example you wont have “text-lg sm:text-xl font-semibold tracking-tight” but will have class “font-heading-2”. Similarly you will create button/input classes that have you basic styles.
Generally you start with just simple utility classes inside html and go from there and where it make sense or its too complex you separate to more complex class. You end up with short css file that only has these special components and none of the basic stuff.
For most elemets it ends up like “flex justify-center gap-4”. In BEM i have to invent “nav-secondary__header” put it in correct place and hate myself when i need to change it to “flex justify-beween”.
Tailwind popularised functional css but is also aimed at masses/noobs. Somehow some of those concepts also resonated with some experienced users.
As an older dev, I think it's a great natural evolution.
We had css, then SASS/LESS/etc, now Tailwind.
In the days of just CSS people would create variables/functions for their CSS in their server side language & have the server side language create the CSS. SASS/LESS allowed us to do that in stylesheets.
Now we have Tailwind (and of course CSS variables). Tailwind (and the code editor plugin devs) have done an amazing job at making a great workflow to handle CSS, especially in component type UI designs.
* Shout out to Foundation and Bootstrap for also helping us get to where we are today. Foundation is underrated in the history.
At that point, why not write these in CSS instead? There is little advantage in using the tailwind shorthand classes in your own class definitions.
- You can use plain CSS variables for theming
- You're bringing back the supposed downsides of cascading and shared classes
- simple Gzip compression will achieve similar size reduction as the utility classes
Working on your codebase now requires full knowledge of the Tailwind utilities, layers, directives, pseudo-classes, theming, and all the complexity that comes along with them.
You’re right - if you only used it for ‘font-heading-2’, you wouldn’t need it.
But like the person you’re responding to said, the ergonomics improve for the majority of cases that are just
‘flex items-center gap-2’.
And yes, you could write it all yourself but Tailwind is a good set of defaults for those classes and minimizes bike-shedding and improves consistency. These are useful things in lots of teams.
I don’t really use Tailwind on smaller personal projects because I love CSS, but in an org of mixed skill levels, it’s pretty damn useful.
(Also, Tailwind uses CSS variables. It had solid support for them in the last major and first class support for it in the current one.)
I was unclear. Yes of course you write these classes “font-heading-2” in CSS. Tailwind is essentialy big list of premade classes to dynamically pull from.
I think the functional approach/structure is the interesting part why people like Tailwind. On very small projects i even make “Tailwind by hand” creating those utilites as i go.
> There is little advantage in using the tailwind shorthand classes in your own class definitions.
There are few massive advantages. I dont have to figure out how to name these classes. Other people in the team know them too. And when they see class they dont know they know its something custom probably for a reason.
> You're bringing back the supposed downsides of cascading and shared classes
I never said cascade is bad.
Creating new flat class with 0-1-0 specificity doesn’t break Tailwind. I’ve been through enough of - everything has specific class that’s nested/scoped… from my experience and usecase it’s harder for little benefit except neater html.
> simple Gzip compression will achieve similar size reduction as the utility classes
I meant custom css that you write by hand and have to scroll trough. Not the result pushed to browser. With functional css you manage to do most of the work in html and what doesn’t make sense you can do traditionaly. For example i dont like doing complex hover interactions in Tailwind so the html has all the layout utilities but also custom class that only has this custom interaction behaviour.
> Working on your codebase now requires full knowledge of the Tailwind utilities, layers, directives, pseudo-classes, theming, and all the complexity that comes along with them.
Is knowing Tailwind naming conventions worse than not having any convention at all? My experience is that Tailwind are just classes that are documented. Without it we would have classes that are undocumented.
There are cases where functional css is not that beneficial. Like in long running products which have single file component workflow where css is scoped and html/css live in same file.
But in work i do in small team we just found it to solve many our painpoints.
Code doesn't necessarily need to be clean. We've had, like, two decades of "do clean code" and a lot of the time that mentality is shit. Putting stuff in a separate file and introducing layers and layers of abstractions to keep things "clean" doesn't always make it so. Often, it makes the code more complex, and makes behavior difficult to reason about.
The big problem with Vanilla CSS is that's it's sort of like Perl. It's a read-only language in practice.
Yes, theoretically, you can have perfect semantic CSS classes and use those. In practice, not every button is the same and you'll need slightly different styling in different places.
Yes, we could go in and change the .button class. But who is using the .button class? Where is it used? Nobody knows, and you can't find out. So editing that class is EXTREMELY risky. I have seen many an entire application break because some dev decided to edit CSS. The bigger the application, the bigger the risk.
Where I work, we have 1500 devs. Does anyone know the complete set of usecases a CSS class would have? No. Even if I gave you a month to research it, you would not find out. So you cannot edit CSS classes, it's far too risky.
So, the result is that everyone just tacks on to the end of the CSS. And now, in your clean code world, you have 50 different button classes. Um... whoops.
If you want to compartmentalize, what you can do is use components, in whatever backend/frontend framework you have. You can have the component have their own state and allow users of the component to change parts of it. Then, it doesn't matter how "unclean" the tailwind is - because you'll almost never see it. But if you need to change it, you can, without destroying the entire application. No more 50 button classes, and no more read-only implementations.
Can I copy some random HTML+CSS snippet from the internet and be sure that it'll look exactly the same in my project and that no existing CSS is going to overwrite it?
I'm never gonna argue learning proper CSS wouldn't be better, but Tailwind is by far the path of least resistance for someone that has no interest in writing frontend for a living. It's like putting legos together, it requires very little thought to get from nothing to a decently looking website.
This is objectively good clean code when you develop it.
Because most of those classes are per component.
If you have a single card component defined with these classes, and then repeat it 20 times on the page, then of course the output will look like a giant mess.
> How did tailwind get so popular?
- quick to understand and get started with
- much cleaner for components than the variety of CSS-in-JS libs
- (mostly) do not require fighting CSS with BEM-style atrocities
- come with nice default styles and colors that can be easily changed and extended
> Learn plain CSS. It's really good now
CSS is okay now. We only just got nesting and scoping
I was a Tailwind skeptic for a long time but I've used it on a few projects now at my full discretion.
However I use it in a much more blended way than the authors probably prefer. I use it with Tailwind Variants and to quickly hack out components. However depending on the project, component, and etc I may also construct BEM-based CSS files to live along side the component.. I use "@apply" in the CSS files, something the author(s?) are on record saying they regret. However I'd counter them by saying if it weren't for "@apply" Tailwind wouldn't be where it is today..
I like how tailwind provides scoping automatically. But in projects already having a build system I use css modules. Writing pure CSS is so much nicer but please don't make me manage class names myself.
I have seen this sentiment on HN a lot recently. Any good resources for that? I was quite the accomplished web developer 15-20 years ago and want to catch up without having to learn a new library or framework every six months.
It is not the nicest but you will quickly get used to it and productive.
However maintaining huge websites with thousands of thousands of lines of custom CSS will never be easy. And especially if somebody else wrote it.
This takes away so many of the criticisms I see in this thread. The issue with Tailwind, and my only minor criticism, is just long, unreadable, not easy to deliminate lists of classes. This very easily takes care of that (and I use it for more complex class lists daily)
I do this to this day, when I’m writing manual vanilla CSS. I group spacings, fonts, texts, borders etc together so it is easier for me to debug without using too many tools.
Before Tailwind, every web designer I’ve ever worked with invented their own version of this.
Yes, CSS in theory is powerful and has everything necessary to avoid using Tailwind, but in practice CSS has a major flaw: You’re almost required to build a semantic model to get the full power. But this ignores that designers are working with mood and emotion just as much as document structure and information architecture. Capturing these more nebulous concepts as logical semantic rules is very difficult if not impossible. Tailwind just codified what everyone already did: Skip the semantic dance (“Making that text bold would be really cool, but what does it mean to be cool, as a general rule?”) and just create semantic rules like “bold” and “red”.
This is the complete opposite of what good CSS is supposed to be. The class name is supposed to tell you what it is not how it looks like. Anyone remember CSS Zen Garden?
The "good CSS" you're talking about was always the product of convention, and it was never sustainable for big, long-term projects. The CSS Zen Garden showcase only made sense in a world where everyone shared the same document or document structure. Those insane stylesheets depended on the source HTML document's inherent structure, which is the exact opposite of separation of concerns.
Inexperienced developers always underestimated the complexity they were adding to their project by using overly abstract classes and hidden structures between the DOM and the stylesheets. Tailwind (or any reasonable CSS methodology even) recognizes these problems and solves them.
I completely disagree. Look at (old) Reddit which allows for individual styling of each subreddit, or VSCode which allows themes to restyle the editor, as examples of real world products separating style from structure to huge success.
Not everything needs that level of separation, but to say that even basic separation is a problem to be solved by jamming everything into the class list is completely wrong.
Doesn't react with styles components (or CSS in js) avoid this? I define reusable components, drawing from a shared theme object. But the styles are still css
I have a feeling that Tailwind started with a good intention to be a utility classes CSS framework, akin to “Bourbon on Steroids”, but people began to accept and use their prototype/sample/example codes way better than they had intended, and they ran with it.
I stumbled on Tailwind in 2018 and introduced it to a team looking to revamp a pretty massive project. I remember that the initial proposal I made was to treat it like Bourbon[1] and write classes that build on Tailwind’s utilities. That way, you can still have `.button`, `.button-primary`, and `.button-primary__accent` etc without the cryptic classes in the HTML.
However, after reading Tailwind, the team found it much easier to write the pre-built classes and stack them as they progressed. And it worked; if I don’t care about how the code is written, things were consistent. It reminds me of “Pixel Perfection” before the responsive design era, when things looked as designed in Photoshop and printed for clients during presentations.
But at what cost? If it’s not a CSS builtin, it’s going to use JS - it may not be something you care about, but it will be there. There’s no other way.
Tailwind compiles all the inline stuff to CSS, and this works in plain CSS. It’s just allowing you to define that inline, which you wouldn’t be able to do with inline styles.
It’s the same as how they enable media queries for example, they’re not using JS just plain CSS, but they’re making it available with these inline classes.
It's not even :has, it's just how child selectors in CSS have always worked.
// Not actually needed, here
// for competition
.group {}
// Child selector
.group:hover group\/hover\:bg-black {
background-color: black;
}
// Which is essentially the same as
.group:hover child {
background-color: black;
}
Based on other replies, I believe they understood CSS well enough, but didn't understand the exact behaviour of the `group` class in Tailwind. Given neither of your comments seem to have made much sense given the context of the discussion, I wonder if you're just looking for confirmation of things you already 'know'.
EDIT: I'm sorry, I mixed you up with the other user who was replying criticising other people's CSS knowledge.
Baseline 2023 meaning all major browsers supported it in their latest versions sometime in 2023.. Like all new CSS stuff it's probably been a very long time coming. Everyone can't pay attention to everything though, regardless of their beard color.
No need to apologize, it just does not make sense to belittle other people's work when you lack the knowledge to judge it. Nobody told you it used JS for the effect, you conjured that up yourself.
No, but `group` doesn't affect the parent in Tailwind. You put `group` in the parent to mark it, and then use the `group/...` syntax to apply different properties to the child, depending on the different states of the parent. This doesn't require `:has`.
I don't think Tailwind has a built-in `:has` tool, but I suspect it would be easy to add one as a custom class.
What do you mean? It's possible to apply attributes to any element in an arbitrary state: `hover:bg-black` would give an element a black background on hover. It's also apparently possible to apply attributes based on whether a state is fulfilled for a child element (i.e. the :has selector). E.g. `has-[:hover]:bg-black` would give an element a black background if any child is hovered.
People would rather have to parse out a big dumb list of classes than look at the actual list of what properties affect something, with a clear ability to drill down into them. Its madness, akin to carpenters giving up hammers, preferring to use glue, because they hit their thumb a few times by accident
On the site I maintain at work, if I check literally any of the old components that don't use tailwind, what I see in the styles list of the devtools is 75 different variants of .card__wrapper or whatever all overriding each other, and it's often an abject nightmare trying to figure out which of the 75 different .card__wrapper (or is it .card { &.__wrapper} ?) classes is the one I care about at the moment.
Click over to the computed styles tab, and now you have a list of all the styles that apply to an element, regardless of source. Click the arrow next to one and it shows you where it comes from
Also, have you ever tried to update old designs using tailwind? It's a disaster. Far easier to know what styles the ugly bem card class you mentioned apply to, rather than an arbitrary b-2 m-1
Based on the code I've seen, including written by old me, it seems more like designing the architecture of the CSS styles (and sticking to it) is something people don't like to do. Tailwind is just a tool that is nicer than using the style attribute on the element.
I strongly prefer "button is-primary is-fullwidth" over the long list of tailwind classes.
We actually ended up adding the custom animation-specific data props to all dialog specific custom elements before the release, so the group-*/dialog is no longer necessary but I forgot to update the code in the post.
I think Tailwind became popular because React doesn't have a good way to combine CSS and JSX in a single file, unlike Vue/Svelte which support single-file components. With Tailwind utility classes you can just add them to your JSX template. React problem solved.
Tailwind tends to be smaller bundle-wise because it will only compile the styles you actually use in the final bundle. The old app I work on, the BEM classes are staggering in their size all combined, whereas the tailwind portions are tiny and importantly barely ever grow in size since the majority of code, old and new, will be using the same "building block" classes like flex p-4 or whatever.
Some people (I suspect a lot of young and motivated developers) think that UI development should be easy and elegant.
But consider that a UI is 100% state management and side effects (so fundamentally imperative and asynchronous). On top of that it takes about three revisions for any tool to require bespoke display of something (everybody has an opinion). They also bring a layout engine which is best expressed in constraints.
And somehow we are trying to shoehorn all this into a functional paradigm.
