I still don’t get the tailwind hype. To me, I think the relevant parties are invested, myself included. CSS is weird and has had a lot of “answers” appended to it out of desperation, but I’ve been feeling really good about styled-components and/or SASS modules, probably slightly in favor of the former, using file based code splitting. I’ve seen the explanations countless times, but if you were to ask me to advocate for tailwind right now, I’d find it difficult to highlight the advantages. The answers don’t immediately jump out at me, the problem we’re solving doesn’t seem immediately apparent, so I have trouble advocating for or understanding the tech.
“You can build stuff quickly!” - doesn’t this just sound like someone comfortable with raw CSS?
“You don’t need to context-switch!” - these are shorthand classes, not JS or JSX. The language isn’t uniform here.
Note: I’ve written a lot of CSS and generally prefer rolling my own components to using a library... perhaps I’m not the target audience. Perhaps this is a cherry flavor to make the “designing your own UI” medicine go down more easily. Perhaps I’m mistaken and not being charitable enough, too.
I think frameworks like tailwind are great for rolling your own components actually. Tailwind sits somewhere between just writing your own styles from scratch and using a css component library like Bootstrap. It provides you with sensible atomics (e.g. a nicely defined range of margins/paddings that allow you to create UIs with consistent spacing), but it still allows you to mix and match where needed.
This approach allows tailwind to be terser than raw inline styles, while giving you the ability to write a lot of your styling inside the markup, which prevents context-switching. It's a nice balance between many of the approaches that have come before it.
Think of tailwindcss an html-level "API" to a Design System - it provides a consistent color scheme, consistent padding/spacing, it uses a familiar naming scheme that aligns closely with the the original CSS naming. It's also easy enough to extend with your own customizations as well, particularly once you get a grasp on the advantages of atomic CSS [0].
I think the fantastic thing about is the natural feeling constraints that it gives you, and not having to think about naming stuff or building out a CSS project (with standards etc) that scales at-all well (which is often a suprising amount of fuckery).
If you're using styled components and you want a small margin you have to do something along the lines of.
Presuming you've set up a file full of font sizes, margins, paddings.
In TailwindCC you get a bunch of very sane, well picked defaults chosen for you for free, by default. You write in a simple DSL and don't have to worry. You can update the defaults as you see fit, too.
<div className="m-1" />
This has autocomplete, etc etc.
IF you don't want the clutter of all these utilities, you can abstract them away into smaller components as you already should be doing. You build your component library with speed and can focus on the actually interesting parts of your system as opposed to wasting time naming stuff or pissing about with CSS.
And of course, if your div is reused a lot, you naturally abstract it into a component at a time that suits you!
I'd say try just using for a project or two and you suddently realise you were wasting a whole lot of time and effort before.
Anything truly dynamic calculated can go also into a style= prop. They work great together!
I was so sick of working web because it felt like working in CSS was a total footgun unless you spend a lot of time making a solution that does things right. Now I find working on web projects a joy again.
If I want this dense notation I can name the custom property `--m-1`. In most IDEs (or language servers) I’ve tried custom properties also have autocomplete.
That is I use CSS custom properties inside component scoped styles. (Component scoped styles is what I call the general idea that React’s styled components are implementing, but Vue’s SFC and the shadow DOM scope the styles to the component at hand equally well).
I’m not saying “Don’t use Tailwind; use custom properties instead”. But for those of us that don’t like the idea that Tailwind brings, there are options, and we are perfectly happy with what we got.
Many people had to try it to really understand what the hype is all about, so it's pretty clearly difficult to explain.
If you give the combination of Tailwind + Alpine.js + your favorite server-side templating engine a try, it may just click. At least for me, that was the key.
To me, it seems like a really bad sign if something that is supposed to solve a problem is “hard to explain”, almost like it doesn’t actually solve any problem and just ropes you in with familiarity.
My assessment is based on the fact that when you design something, you generally have to be able to explain its value, with little exception.
What I don’t get is that everyone is always acting like Tailwind invented this approach to CSS. It’s been a thing for at least 6 years or more, far before tailwind. Granted I suppose they have really brought it to the mainstream.
As someone who’s used this approach in production for years I can vouch for it. It greatly reduces complexity and is easier to maintain. Day to day no one is writing any css at all, nor are they bogged down with naming conventions, etc. You just “snap” together your utility classes ad-hoc as needed.
Responsive breakpoints are also much easier to work with because they’re just “built in” as modifiers on all the base utility classes.
Tailwind is quite convenient for standard web projects. The advantages are less apparent in React projects, especially if you use styled-components or robusts frameworks like ChakraUI.
Note: I’ve written a lot of CSS and generally prefer rolling my own components to using a library... perhaps I’m not the target audience. Perhaps this is a cherry flavor to make the “designing your own UI” medicine go down more easily. Perhaps I’m mistaken and not being charitable enough, too.