(Again, I realise the failure is probably on me. But I don't get it.)
Tailwind is essentially unusable without a build step. You can configure it to make composite classes for common styles (button, card, etc.), but if you buy into their philosophy you'll probably want a component-based design (web components, React, Vue, etc).
It's better than working with CSS manually because you work at a slightly higher level. If it was transformed into a css-like language I would prefer that. As a non-UI expert, I also enjoy having an enumerable limited set of sane choices for most properties.
With tailwindcss or tachyons you get some of the benefits of component frameworks without having to use component frameworks, because you can colocate html & "styles" in regular template based systems and scope sections on a page this way. Great DX if you need to render sections conditionally, e.g. for ab testing.
If you think in sections rather than individual components anyway, which tailwind kind of promotes by design, you don't gain that much with a component framework.
The actual CSS functions like an inverted triangle (see ITCSS) the utility classes access from the html, so you won't have any specificity issues because it's already sorted out by having the CSS in a fixed order.
Another advantage is portability of sections between modern frontend JS frameworks and template based systems, you can just copy and paste things around, which is harder if the information about the styles is separated from the html, and without a fixed inverted triangle like CSS structure.
Isn't a section just a case of a component?
Yeah, a section is a component, but in my book it also involves the visible page background where the element is located (you could override the page background with a section color), like a slice of the page.
Tachyons has truly taken a lot of the pain of writing web applications away for me. It looks kind of ugly in the beginning, but I can't imagine going back to writing oodles of CSS again. Haven't used Tailwind though.
I am now a convert and although it's hard for me to articulate exactly where the magic lies, these are contributing factors:
- You can do the entire thing in HTML quickly, including media queries and pseudo-classes.
- The predefined sizes and other values are granular enough that you can do just about everything with them, but coarse enough that you often get it right in the first shot. In a sense, it's a little like going from drawing a chart on blank paper to grid paper.
- Tailwind intellisense in VSCode shows you the colors you likely need.
Each of these points are tiny and could easily be achieved in another way, but combined they have increased my personal joy in frontend development quite significantly.
https://tailwindcss.com/docs/utility-first
The core principle is that you wrap up all UI elements into components. Most frontend and backend/template frameworks allow you to do this. You then verbosely apply the Tailwind classnames to perform styling, staying out of custom .css files all together.
I was skeptical of Tailwind too until I actually tried it. It’s one of those things like JSX that defies received wisdom but in real use is very nice.
Do people really struggle with this?
<div class="hero">
<h1 class="hero-title">Heading</h1>
<p class="hero-tagline">Tagline</p>
</div>
> You need to go digging around in all your stylesheets to figure it out and in most cases actually load up the page and inspect it.
When are you changing CSS and not inspecting the page at the same time? You are going to have to check your work. This doesn't happen if you keep things tidy as you go along. Working in a large team and/or scrum is no excuse for checking-in poor code.
Generally what the code is doing should be fairly obvious and should not need comments. Comments should be reserved where things aren't obvious.
I don't think it is a good idea to create code where it isnt obvious what it does. CSS is relatively simple tbh things really shouldn't be complicated.
I've been building sites the way you suggest for 20 years. I also had a negative knee jerk reaction to tailwind. But I had enough of an open mind to try it and now I have no interesting in going back.
People say that. If you build stuff in components like you are supposed to you almost always have a server side component or component logic that you will have to name. So you are going to have to start naming things properly somewhere.
You are simply kicking the can down the road.
> I've been building sites the way you suggest for 20 years. I also had a negative knee jerk reaction to tailwind.
It isn't a negative kneejerk reaction. I've worked with sites where they have done similar things to tailwind and it is a nightmare to understand what is going on with the page.
> But I had enough of an open mind to try it and now I have no interesting in going back.
The markup is almost unreadable, it completely defeats the point of what CSS is supposed to do and it creates considerable mental overhead for someone who isn't familiar with it.
But I suppose I shouldn't really expect anything else from other web developers that over the last 20 odd years somehow manage to not understand the tech they are given.
And despite your crude last jibe at web developers attracted to Tailwind's model, most competent web developers will be able to quite easily pickup this very sane CSS utility framework :)
No my jibe was at web developers in general. CSS and HTML are quite simple really. If you actually keep things semantic and build your document properly with appropriate markup ... lo and behold things just work properly.
I can understand the divistush of the past when CSS 1 and 2 were quite limited. However today there is simply no excuse.
> most competent web developers will be able to quite easily pickup this very sane CSS utility framework :)
Sure I can read it. The problem is with things like this is that you are learning how to work with their model that basically doesn't work like CSS is supposed to work.
So you it essentially nullifies your existing skillset and forces you into using their framework. I bothered to actually learn CSS properly and understand the technology and then I have to work with something which basically throws that all out the window and forces me to work how they want me to build stuff. No thanks.
If you think that is a "sane" way of working, I really don't know what to say.
Sure, so you can do it once and use functional css to define the styles that go with that component right alongside the markup instead of having to maintain another css class name for that component in a separate file, mostly likely with arbitrary and inconsistent padding and margin and font-size values.
- The classes cover many common use-cases and, in some cases, present a simpler "API" than hand-rolled CSS would
- You can eyeball a HTML fragment and get a good idea of how the pieces fit together, compared to the normal approach of needing to work out what each individual class does, and then how they fit together. It's easy to remember what the Tailwind classes are doing.
- It's dumb, but the ability copy-and-paste entire HTML fragments from one place to another and have the styling "just work" is slightly mind-blowing
- Some CSS attributes work oddly depending on the order in which they are applied, or the order of the composition of classes that both attempt to apply the same attribute, and that problem goes away with Tailwind
There are other advantages, but these were all quite surprising to me, because my expectations of CSS have always been quite low.
Not really. styled-components makes this simple if you're using react.
After watching a few of those I started thinking about how much faster it could be to use these utility classes instead of writing it by hand. Everywhere he adds a few quick classes I was thinking "here I'd be going back to the CSS, hunting for that class name, maybe duplicating it to create a unique variation... and it took him 7 seconds with a utility class. Hm."
Haven't gotten to try it on a project yet but it's on my list.
My take is that it's not. It's just a convenient shortcut for those who aren't well versed in CSS.
I see what kind of problem they're trying to solve, but I think it collapses under its own weight the same as complete, closed components do - just later into the project.
I don't necessarily want to remember 30 different context-specific class names when adding a new link or button on a simple page if I know a bit of syntax I can get exactly what I want, when I want it.
Again, it's very much a project specific choice, but when you're playing and tweaking and having fun with a design (or simply, iterating on one element multiple times), it's a nice library.
That being said, I can imagine a point where once you're happy with a design, there'd be a push to refactor.