271–280 of 296 posts
Earlier quoted context omitted.
Do you have an example that Tailwind can do that can't be done in CSS?
I'm going off a claim from the Tailwind site :-) The original question wasn't whether Tailwind can do something CSS can't, but whether it was a 1:1 mapping. Can regular CSS do media queries all within the element's style attribute? I believe Tailwind also utilizes JS to get some convenience features to work.
I used tailwind for my site and ended up liking it a lot, but maybe for reasons that are not often mentioned? The real value of tailwind is being able to read all the styles that affect a an element in one place. Sure the classnames can get long, but it’s still a lot faster to read that long line, than open the browser tools each time or scroll up and down one (or many) stylesheets. Then when you come back to that co…
> real value of tailwind is being able to read all the styles that affect a an element in one place there are helpers for that in the IDE (e.g., "Show Applied Styles for Tag" in Intellij) or even in chrome dev tools that show all this in a readable way. Tailwind snippets mentioned in this HN topic look kind of scary in comparison.
There's those that never used it for more than 30 minutes, that just tried it out or just skimmed through the docs. Those are the people that hate it and prefer "vanilla CSS" or similar.
Then there's the people that actually used it for a real project, within a team with more than 1 single person. Those are the people that understand its value, accept its trade offs and love it.
I've seen a lot of people jump from the first group to the second group. I've seen almost none jump from the second to the first.
That's why Tailwind is so successful.
It might not be beautiful in the eye of the purist, but it's absolutely fantastic in the eye of the builder and pragmatic.
Earlier quoted context omitted.
You’re doing something silly living without a lock file to use a tool as part of your build process. Why don’t you actually include the version of the tool you want in your dev dependencies + lock file? That way, you don’t get broken. We’ve had the solution to this problem - lock files - for 15ish years, since Ruby’s `bundle` introduced it.
Not everything is a node App. We don't have a lock file because we don't have any local npm dependencies (as already mentioned). We're using `npx tailwindcss` as-is.
Question for those developers who, like me, have no f/end build step: How would I use tailwind without a f/end build step? All the examples of using tailwind 4.0 on the linked site assume a f/end build step. My project does not use (and I have no plans to include) npm, or PostCSS, etc.
This is what keeps me from using Tailwind too. I simply do not want to add the maintenance headaches of an npm-based build process to my project.
Plus I couldn’t imagine developing without TypeScript and hot reloads in 2025.
Earlier quoted context omitted.
I just want the color palette of the Tailwind CSS.
yeah, the palette is neat. My main gripe with Tailwind is that it blends a set of design tokens (which I like) with a technology to apply them (which I don't like)
Earlier quoted context omitted.
you can use @apply to merge the various utility classes together in to something resembling a name, like .btn-primary { @apply py-2 px-5 bg-violet-500 text-white font-semibold rounded-full shadow-md hover:bg-violet-700 focus:outline-none focus:ring focus:ring-violet-400 focus:ring-opacity-75; } But their v3 docs seem to be very against this. "Whatever you do, don’t use @apply just to make things look “cleaner”. Yes,…
I agree with Tailwind's stance on this. You really don't need @apply if you're breaking things down to smaller components. I often see people have things like text1 text2 ... . This is where I think we need a linter to warn against things like that. Make those 's a component!
Earlier quoted context omitted.
What did you need Tailwind for before that you couldn't do in normal CSS? Doesn't Tailwind map pretty much 1:1 to CSS?
Every programming language maps 1:1 to CPU instruction sets, but very few humans want to speak CPU language directly…hope that helps.
There's a clear pattern in every "Tailwind or not tailwind" conversation (which happens everytime Tailwind is mentioned). There's those that never used it for more than 30 minutes, that just tried it out or just skimmed through the docs. Those are the people that hate it and prefer "vanilla CSS" or similar. Then there's the people that actually used it for a real project, within a team with more than 1 single person.…
I’m not against Tailwind, but I didn't used it yet because I struggle to see why it's a better approach compared to other options like Web Components or React Styled Components.
The biggest issue I have with Tailwind is how it clutters the HTML with a ton of utility classes making the HTML harder to read and maintain. Of course I see Tailwind being better than using large global CSS files with the classic CSS approach of naming html tags. But we do have ways where the CSS is scoped to a component without polluting the global namespace. Like Web Components and Styled Components. Both keep styles tied directly to the component (or more general, a specific group of html tags), making it easy to see which styles apply where.
And yes, with them there’s no need for global class names, without having to worry about unwanted side effects or clashes. If I remove a component, I also remove its associated styles without worrying about unused CSS being left behind since both are tied together. Plus, there’s no risk of one component's styles unintentionally affecting another (thanks to shadow DOMs).
I really value keeping HTML very short and readable by not mixing presentational styles directly in the markup. Tailwind’s approach, where the styling is all in the class attributes, makes the HTML feel cluttered, especially when you have long class lists on a single line, and GOD forbid you have actual class names to use there. It’s harder to understand what styles are applied at a glance since you cant even have it well indented, and it clearly reminds many reasons why we moved away from the inline style attribute in HTML in the first place. (Yes, we didn't left it for its limitations like pseudo classes and @media queries, they didn't even exist, we didn't add those new features because no one wanted to get back to those inline styling)
So, while I don’t hate Tailwind, I just don’t see the clear advantages over Web Components or Styled Components in terms of readability, maintainability, and separation of concerns, while I do have important unanswered important concerns about using it...
Yes, I've read the docs but never tried it out, I don't hate it, but I can't understand why I would choose it over other options. The fact of having a million classes in the middle of plain HTML makes them both unreadable for me.
And No, I don't like huge CSS files either, or the classic approach of using them. But it is hard for me to see why tailwind is a better approach than working with Web Components, or React with Styled components.
These two approaches allows me to not have to read presentational things in the middle of my html, and allow my html to be more clear and readable. I don't have to use CSS class names, it's easy to identify which CSS applies where, so, if you remove the component, you remove the CSS too, you don't end serving unused CSS rules. Each can have CSS not leaking to the global scope, and there is no risk on changing styles of another element...
So, there is no hate for me, but it is very hard for me to see the benefits of tailwind over these two approaches, and I really dislike the idea of having to read html elements with huge styling rules cluttering my html files, and worse, having all of them in a single line makin it hard to understand all the applied styling.
We left using style tag from HTML mostly for that reason, and not because of its current limitations (like not being able to use pseudo classes, media, etc)