A large company with frontend specialists and CSS experts might not need Tailwind - and indeed they might find it gets in the way. Personally I find it lets me build and maintain decent UI layouts with minimum fuss. When I'm repeating myself with too-long class strings, I can either use @apply or wrap the markup in a component.
Some people did have a visceral hatred of Atomic CSS, but even those people were able to solve problems with it very quickly, without having to dig on tens of CSS files that happened to affect a single component.
Hmm, that would be interesting data to use to analyze the CSS quality of a site. If you used the sourcemaps along with a rendered html page you could find which elements had styling from the most separate css files which might give you clues on where to improve your CSS.
There's only two ways to avoid it: having very small, very cohesive, teams, or using tools and methodologies that avoid this.
This is one of those things that gives me the feeling the true "10x" engineer mostly just writes code to some reasonable architecture standard and does their best to avoid tech debt. Speed in the longer term means avoiding these situations if you ask me
However that also means its perfectly ok to have one’s own system (cf. twitch, github...). Why not use a standard though? Tailwind saves us so much time coming up with a solid consistét utility set.
And then combine it with Sass
If anyone familiar with how Tailwind works lands on a new project, regardless of its age, this person can immediately understand the front-end code in a matter of seconds, without having to look through thousands of lines of code in a separate CSS folder.
I don't understand why Tailwind is "harder to read", as the OP wrote. It makes it much easier to read as what the code does is immediately understandable.
I had to eg. fix a stacking context issue (z-index) a so called full stack dev could not solve. Basic css technique.
For someone creating layouts from scratch tw is very verbose and templates can become difficult to reason through while you develop them. Easy to disregard for devs who just jump in a ready made template and make smaller changes.
Others view compartmentalisation as important to ease of reading, letting them focus on one level at a time.
I wonder how well the preferences for tailwind align with people's views on unit tests in the same source file?
In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else. With class-based styles, even when using theme variables, there is always the chance you end up breaking something at a distance by adding a property to an existing class, changing a shared value, renaming a selector or changing it's precedence.
If you find yourself in this environment where dozens of people are making changes concurrently, and these issues are a daily occurrence, naturally you'll wonder how you ever worked with CSS any other way.
styled-jsx and other approaches can get you similar benefits but extra care is necessary. I mostly avoid Tailwind due to the lock-in, complex setup and slow build, otherwise might have used it for quick prototypes more often.
Isn't the flip side of this that it makes it almost impossible to keep styles (visually) consistent across the codebase?
.button {
@apply py-2 px-4;
}
.button {
padding: var(--medium-padding) var(--medium-padding);
}
The point of Tailwind is that it’s a straightforward way to handle all the CSS complexity and put the moving parts into a single config file that works the same everywhere.
Tailwind: https://tailwindcss.com/docs/theme#spacing
Would it be strange to define p-2 to be smaller than p-1? Yes. Exactly as strange as defining your padding-medium variable to be smaller than padding-small.
However, the Tailwind team are very close to releasing something that is, apparently, going to dramatically speed up build times (source: Adam Wathan's recent tweets).
I sometimes wonder if people even understand what technology they are using:
CSS = Cascading Style Sheets
Go read some history, as to why exactly they were created. What you are describing is not CSS at all, that's properties on a design grid.
Which goes back to the author's point - if you want or really need that, don't use CSS. Just use components with standalone properties.
Use CSS when you want to be 100% sure it will change everything else.
I switched to TailwindCSS a long time ago and I have zero regrets. Its so awesome I can switch to a project that is 2 years old, and make a quick layout UI change without having to look at old CSS files to find classes etc. I also can just find a tailwind class name and apply lots of cool stuff that I've normally found difficult to do via "pure" CSS files.
But I also feel that this is likely to be a thing that half prefer A, and half prefer B, and there is nothing wrong with either. In this thread is likely to be a 50/50 split between both camps, with different "ideologies" on how the front end should be done.
As the author of this article says - give it a go. If you like it, awesome. If you dont, switch back to another tool, there's not a definitive "right/wrong" answer to any of this.