.eslintignore can be replaced by an ignorePatterns key in .eslintrc.cjs
Unless you’re ignoring entire directories or using Prettier in your editor, .prettierignore can be replaced with // prettier-ignore comments in files you want to ignore, or specifying globs in the command line (usually in the package.json script fields)
The entirety of .prettierrc can be replaced by a prettier key in package.json
Everything that ends in .ts, .js, and .cjs a script, not a config file, and they could all be moved to a separate folder and pointed at with command line flags
All of the options above are categorically worse than the standard layout
pnpm-lock.yaml and flake.lock aren’t config files and shouldn’t be edited unless you know what you’re doing
Sure, some people will have that reaction. In my anecdotal experience you’re part of the absolute minority though, at least 80% of devs I know who have tried Tailwind love it.
But is it not really annoying to redefine the entire style in the class list of every component? Like if you have multiple things that look almost identical you need about a dozen classes that are identical on each and if you ever want to change that you have to go through each of them and change it, rather than using css classes how they’re actually supposed to be used and changing it in a single place
That’s where the good system design part comes in.
If you have a dozen identical looking components, they should have been one component imported into a dozen places. Keep it DRY.
If you’re more concerned about stuff like common borders or background colors being applied everywhere, you can always use the “@apply” directive to create a new reusable class.
Tailwind makes creating and iterating through design concepts so much faster and easier if your system is designed well.
I agree that it’s useful if you’re trying to create something quick and small but as soon as you want to do anything where there’s complexity that needs to be kept consistent then it falls apart for me. Surely tailwind is the exact opposite of DRY with the way you specify properties directly on the component instead of in a normal css system?
Tailwind isn’t any more or less DRY than normal CSS.
First off, it’s rare to use CSS in the intended way these days - scoped styling has become very popular for good reasons, which means component styles are either already separated, or you’re importing things. This doesn’t change with Tailwind, you can still import things just the same.
But where it shines is removing the need for arbitrary class names. Almost every CSS codebase I’ve seen used class names differently, sometimes even for the same thing. How often have you seen .container overloaded with different meanings? Instead of having to come up with individual class names that might or might not actually be descriptive, I connect the styles to the elements that use them. No more jumping around between CSS and JS, no more arbitrary names - classes have well-defined name structures that you learn once, and use for every project after that.
I’ll use Svelte as an example. In Svelte, you can just put a style tag at the bottom of your component, and everything you put in there is automatically scoped to it. I’m not hunting through dozens a CSS files trying to find where a class was overridden and adding !important everywhere. Using vanilla CSS allows me to keep my markup clean and concise so I can better see the actual structure of each component without dozens of CSS class names cluttering everything up.
Sure, you can write your own class in Tailwind using the @apply directive, but why not just add a global CSS class? That’s essentially what you’re doing anyways. And now you don’t have to hunt through multiple layers of abstraction to figure out what styles are actually being applied.
In my experience, Tailwind was good as long as I didn’t try to do anything too interesting. What ended up happening in my project was that I would use Tailwind classes for basic styling, then break into vanilla CSS whenever Tailwind wasn’t sufficient. And that meant I was looking in multiple places to see what styling was affecting my component… which kinda defeated the purpose of using Tailwind.
Personally, I also just found Tailwind harder to read. I prefer to read code vertically rather than horizontally.
It does remove a small aspect of its usefulness, but the other ones I’ve mentioned still exist.
I’ll use Svelte as an example. In Svelte, you can just put a style tag at the bottom of your component, and everything you put in there is automatically scoped to it. I’m not hunting through dozens a CSS files trying to find where a class was overridden and adding !important everywhere. Using vanilla CSS allows me to keep my markup clean and concise so I can better see the actual structure of each component without dozens of CSS class names cluttering everything up.
Several points:
You still have to hunt through the file to find any selectors applying to your elements. There’s still a bunch of vertical jumping around.
How often do you actually need to see the structure of your DOM without styles? I want to see it with styles much more often than without.
You still have to come up with unique class names for everything in your DOM, or you’ll have brittle selectors. This means that for every single component in every single project I have to learn the class names, and they might even change over time. This is a lot of overhead.
In my experience, Tailwind was good as long as I didn’t try to do anything too interesting. What ended up happening in my project was that I would use Tailwind classes for basic styling, then break into vanilla CSS whenever Tailwind wasn’t sufficient. And that meant I was looking in multiple places to see what styling was affecting my component… which kinda defeated the purpose of using Tailwind.
You almost always have to look in multiple places with normal CSS styling, since it’s cascading. If I can solve 95+% of my apps styling needs inline and just break out for special cases, I still remove most of the jumping around and class name overhead and so on. This is still a massive advantage.
.eslintignorecan be replaced by anignorePatternskey in.eslintrc.cjs.prettierignorecan be replaced with// prettier-ignorecomments in files you want to ignore, or specifying globs in the command line (usually in thepackage.jsonscript fields).prettierrccan be replaced by aprettierkey inpackage.json.ts,.js, and.cjsa script, not a config file, and they could all be moved to a separate folder and pointed at with command line flagspnpm-lock.yamlandflake.lockaren’t config files and shouldn’t be edited unless you know what you’re doingEveryone disagrees with me when I say this, I’m glad to find someone else who sees through the lies
I’ve seen plenty of people say what you’re saying - though they usually change their tone once they’ve actually tried Tailwind.
I’ve tried it and I still hate it
Sure, some people will have that reaction. In my anecdotal experience you’re part of the absolute minority though, at least 80% of devs I know who have tried Tailwind love it.
It’s bad if you don’t have a design system. If you have a design system it’s :chef’s kiss:
But is it not really annoying to redefine the entire style in the class list of every component? Like if you have multiple things that look almost identical you need about a dozen classes that are identical on each and if you ever want to change that you have to go through each of them and change it, rather than using css classes how they’re actually supposed to be used and changing it in a single place
That’s where the good system design part comes in.
If you have a dozen identical looking components, they should have been one component imported into a dozen places. Keep it DRY.
If you’re more concerned about stuff like common borders or background colors being applied everywhere, you can always use the “@apply” directive to create a new reusable class.
Tailwind makes creating and iterating through design concepts so much faster and easier if your system is designed well.
I agree that it’s useful if you’re trying to create something quick and small but as soon as you want to do anything where there’s complexity that needs to be kept consistent then it falls apart for me. Surely tailwind is the exact opposite of DRY with the way you specify properties directly on the component instead of in a normal css system?
Tailwind isn’t any more or less DRY than normal CSS.
First off, it’s rare to use CSS in the intended way these days - scoped styling has become very popular for good reasons, which means component styles are either already separated, or you’re importing things. This doesn’t change with Tailwind, you can still import things just the same.
But where it shines is removing the need for arbitrary class names. Almost every CSS codebase I’ve seen used class names differently, sometimes even for the same thing. How often have you seen
.containeroverloaded with different meanings? Instead of having to come up with individual class names that might or might not actually be descriptive, I connect the styles to the elements that use them. No more jumping around between CSS and JS, no more arbitrary names - classes have well-defined name structures that you learn once, and use for every project after that.IMO, scoped styling removes Tailwind’s usefulness.
I’ll use Svelte as an example. In Svelte, you can just put a style tag at the bottom of your component, and everything you put in there is automatically scoped to it. I’m not hunting through dozens a CSS files trying to find where a class was overridden and adding !important everywhere. Using vanilla CSS allows me to keep my markup clean and concise so I can better see the actual structure of each component without dozens of CSS class names cluttering everything up.
Sure, you can write your own class in Tailwind using the @apply directive, but why not just add a global CSS class? That’s essentially what you’re doing anyways. And now you don’t have to hunt through multiple layers of abstraction to figure out what styles are actually being applied.
In my experience, Tailwind was good as long as I didn’t try to do anything too interesting. What ended up happening in my project was that I would use Tailwind classes for basic styling, then break into vanilla CSS whenever Tailwind wasn’t sufficient. And that meant I was looking in multiple places to see what styling was affecting my component… which kinda defeated the purpose of using Tailwind.
Personally, I also just found Tailwind harder to read. I prefer to read code vertically rather than horizontally.
It does remove a small aspect of its usefulness, but the other ones I’ve mentioned still exist.
Several points:
You almost always have to look in multiple places with normal CSS styling, since it’s cascading. If I can solve 95+% of my apps styling needs inline and just break out for special cases, I still remove most of the jumping around and class name overhead and so on. This is still a massive advantage.
I tried so hard to like tailwind. It’s just so… hard to work with.