If I want to change the color of my buttons, I go change the "inline CSS" of the Button component I am using everywhere, and it changes everywhere.
My point is just that "If I want five buttons to change, I have to go find five places to edit it" isn't the reality of working with the tool in its intended way.
The approach Tailwind takes is that since the component is named and contained, its elements don't have to be named explicitly. And while we could then use inline CSS, it has some limitations so utility classes are a more powerful tool.
https://svelte.dev/examples/styling
I’d say that goes halfway toward solving the problem Tailwind solves and could well be enough for most people. It’s nice not to go to a different file, and it’s nice to get scoping. But you still have to come up with class names, and you still have to mentally match up what classes go where.
If you find yourself repeating a certain combination of classnames over and over, you should refactor to make that a variable and use it in all the places where the repetition is. You might ask how is this different from CSS if these variables containing inline css are just classnames under another name? I would respond that they are basically the same thing, but Tailwind excels in the case where you need a style "just for this one spot" because you don't have to create a classname and edit two different files (html and css) to achieve the effect.
Inline style attributes and <style> blocks already solve this...
I suspect most of the mania around CSS frameworks is that people don't grok that you don't HAVE to put everything in one big external .css file -- there is a spectrum of ways to declare CSS and with modern browser dev tools it becomes easy to understand where each rule is coming from.
Sure. The point of tailwind is to make this nicer, not to fully replace it.
I find the naming scheme and helpers they provide to make writing CSS a lot easier. Mind you, I would never claim to be a CSS expert in the first place. But Tailwind isn't trying to be something different, it's trying to make something easier and better.
I like vim too. I feel like there's a vague similarity here.
Some stuff makes sense like the "flex" classes but IMO the margins, paddings, text sizes, colors is extremism.
The benefit of Tailwind is that it standardizes styles. Even in a small button component, I’d have to create classes to attach my styles to. New team members would then have to figure out how and where something is defined.
With Tailwind, any developer familiar with it can search for „bg-blue-500“ and turn it into „bg-red-500“.
So it’s mainly a solution for large websites and teams. On a small, handmade website, well thought out classes in a central stylesheet is definitely the way to go.
I’m my opinion, the benefits of Tailwind are debatable and I really don’t like the readability of it. Any complex component will have a need for classes that are assigned depending on other variables and conditions so the naming problem doesn’t go away either. So in the end I favor component scoped CSS where my HTML is concise, with a few classes and conditions and then a style tag below.
I understand Tailwind works and gets the job done and is probably more accessible than learning CSS, but do CSS experts also prefer it?
I lived through every CSS fad for writing "maintainable" css, and have settled on Tailwind. It doesn't limit you, you can always add normal old css files to your project if you need / want to.
But what it means is I don't end up with a `utilities.scss` of `.flex` `.block` etc etc etc, which you always do on any project. I get a full catalogue of utility classes that only get included in the generated css if I use them in my project, I don't have to think about class names, and I don't have to open a separate css file.
The only con is sometimes an absolutely ridiculous amount of utility classes on an element, but frankly scarlet...
Tailwind can be a very productive tool that feels odd at first and remains odd for elements like input fields but absolutely has its place. It comes with a fraction of the foot guns typically associated with CSS for the tiny cost of looking a bit silly at first. And this is coming from someone who loves (near) class-less CSS frameworks.
No, and this has been discussed ad nauseam in every discussion about Tailwind, ever, especially here.
I'm not a huge Tailwind advocate, but the difference between it and inline styles have been explained a million times.
It's like saying "wow so this language uses an immutable string type and vaguely C-like syntax! Is it Java?"
Except for the difference that Inline Styles strictly cannot do the same things that TW can do, without the help of another stylesheet or CSS block.
js, html, css > all within the proper component context in a reasonable OO form (react fx can fx right off)
And, Imba global css classes are importable to other tags at the top level, no need to reimport, just .class-me
.color-primary { color: white; }
.some-text { @apply color-primary; }
There is plenty of info out there about why Tailwind, or rather utility-first in general, works in many situations. The "classic" way is still also appropriate. I use both depending on the project, though I really like Tailwind and is by far my favourite method most of the time. I say this as someone in their 40s who has been enjoying writing CSS since it was first introduced in the late 90s (yep, guilty of Stockholm Syndrome here).
Tailwind is "SQL" for CSS
I'm not blaming OP, the question seems innocent enough, but I had this bias and some others myself until I used Tailwind for an actual project and have never looked back, and most of the criticism that appears in HN is just misunderstood concepts and harsh sounding soundbites.
I distrust HN's general sentiment on stuff more (if there is such a thing but you know what I mean), I check for myself.
Regarding tailwind specifically, it's the modern way of "just css" which goes amazingly well with having the component abstraction level.
You don't abstract your css, you keep it all in base level, you abstract components, in this particular case you would go to your button component and change all of the application's button at once.