FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
59% Positive
Analyzed from 4400 words in the discussion.
Trending Topics
#css#tailwind#class#don#button#classes#color#code#components#need
Discussion (95 Comments)Read Original on HackerNews
The conventions and class names come really naturally fast, and you can always look it up. It's just not as a big of a problem people make it.
But the most ridiculous part of the article I found the cascade complaint:
Yes, this does not work. Why should it?! There is not a single use case where this is a good idea! In classic CSS, you might want to override something based on modifier classes, but that is just not a thing with Tailwind! If you end up programmatically layering class names, you're looking at a code smell. Instead, you want to use attribute or state modifiers, like `aria-hidden:opacity-0`.Why wouldn't you? Suppose you have Button class with `btn btn-primary`. The Button accepts className override so you can do <Button className='btn-secondary'>. In this case you use tailwind-merge or clsx. Your Button implementation would be clsx('btn btn-primary', className), in which case right most class name prevails.
Other than that, I agree tailwind is great. It lets you keep things all in one place. Names aren't particularly difficult to memorize and reason about and autocomplete does a great job. Build utility classes or proper components to encapsulate the styling and you're fine. What benefit do I have going to a css file to review my button styling over the actual Button component?
It's so common, that there is an expensive runtime package, `tailwind-merge`, that is used by default in the most popular component library.
It's a red flag (ha).
The random outcome, entirely dependent on the Tailwind generation internals, is the worst of all worlds though, it's just an unfortunate side-effect of relying on cascading sheets to drive atomic styles.
Is it ideal? I guess not, but there are a lot of weird gotchas and footguns in CSS too. Just because they’re in the language doesn’t make them magically more or less of a problem. For a similar weird mental shift, consider adding @starting-style and the native popover open attribute. All the good tutorials online have a warning about cascade order because as a human reading it, it can seem wrong or backwards.
Kevin Powell’s most recent video about animating display: none covers it if you want a concrete example.
And at that point, onboarding a new developer always means wasted time on understanding this whole organically grown set of bespoke conventions, class names, patterns, hierarchies, and so on.
Tailwind does not really have this pattern of deterioration growing along both time and complexity, it stays consistent on both axes. So it's definitely an argument IMHO.
One, adding classes from the outside to an encapsulated component with its own, internal classes, to make sure the outside-applied classes take priority. Either use the !important modifier on them (`ms-auto!`), put the components into a container div with the classes for layout concerns, or even better: Figure out why you need to make styling changes to a component that cannot be expressed via props. I would generally recommend components to not have outside-element styling like margins in them anyway, which most often fights with positioning later.
Two, merging prop-derived styling with base styles - for example for a `size: 'sm'|'lg'` prop. It's tempting to just use tailwind-merge here:
But that isn't necessary at all: The better alternative would be to use data attributes for visual concerns and built-in or aria attributes for interaction states. There are almost always element attributes that can represent what you want to have correctly, and data- where there are not. Then, you can just add a class accordingly: And you'll end up with easier to maintain components that derive their styles from the CSS cascade alone.No? Neither did I. I stopped thinking about CSS entirely almost a decade ago. Thanks Tailwind.
What I would have is:
- a global palette specified via CSS variables
- overrides for dark mode etc specified at the global level so I don’t have to worry about it at the component level
- CSS module files so I specifically don’t need to care for the context of my entire project, just the classes for my current component
Of course, you stopped thinking about CSS a decade ago so you don’t know about any of these improvements. Which is fine but it strikes me as a little strange to be so boastful of ignorance.
As someone who has barely touched Tailwind I’m genuinely curious: if you wanted, say, a consistent border color for use across your project how would you? Are you defining a class name in JS for use with $framework_name? And do you really style each component separately for dark mode? Repeating the same modifiers over and over?
That handles consistent sizing, spacing, text, colors, dark mode, and anything else your design system needs. It all compiles down to css in the end, so no runtime overhead and gives you the superior tailwind dx during development.
And as you say, it’s for semantics so I wouldn’t use .button anyway as it doesn’t carry the right specificity for styling.
And just a shared color definition file.
So you end up wrapping the components (if you’re using react or something similar) so that you can centralise the styles and use a set of consistent components instead. And at that point it really doesn’t matter if you use tailwind, custom classes, per component css modules, style attributes, css-in-js, or what have you. At this point I prefer to drop the extra dependency and use per-component css files with css module imports. (Or when I do less custom styled UI’s, I prefer to use Mantine and use its attributes for layout and styling)
It's a matter of preference, but many times it's easier to have single classes so that all your buttons are consistent.
People should just use the tool they're more productive with.
Could you give us a few examples with and without Tailwind, including CSS variable and compose in preprocessors?
you just add `checkout` class or `big` class to your button. or use `.checkout-page .button` to modify look/size of your whatever button on the checkout page if it's style is truly unique and not used anywhere else.
Turns out, CSS Modules comes with the same benefits while feeling much more like a natural extension to the web platform. The only thing I thoroughly miss is functions and directives, which hopefully will land in browsers through the mixins proposal in not too long of a time.
Never looked back. Also, inheriting projects with someone else’s code is fine. Just a quick look at the central config and you’re good to go.
Constraints are known to enhance creativity.
Tailwind CSS is Python dictionaries where you don't create one user-order-deliver-date CSS class for every Noun you have.
On simple projects I usually @apply tailwind styles to standard elements like headings, block quote, aside, nav etc. Then just use semantic html.
Looks good and takes so little effort.
Also works great with agent assisted development.
But this belief is only true if the language to describe the structure is html or js which creates not reusable pieces of style/structure.
But when you go for a different approach where everything is functions and strong types (ADT), like when you use haskell for exemple, this debate is over, because you handle EVERYTHING in your code, and stop fragmenting the truth into opaque and dissociated worlds (html, js, css, database, glue, docker, ...).
But your approach is from the past man, really... .btn is not reusable among pages / projects / etc. => it's always different, and when you understand that specificity wars is the main problem of css, you will not want to use your idea again.
It LOOKS cool to have a <button class="btn"> inside your html. because it's more readable. But it's NOT explicit. You fragment truth into different pieces. and it makes it IMPOSSIBLE to test things in isolation.
One last thing. Using all the "last features" of css is just putting you in a place where you depend on the browser carriers to handle things for you when I prefer personnaly to rely on myself and my craft. But that's a personal one ;)
The purists ("that’s how things ought to be!") and the pragmatists ("well but it works well and people understand it seemingly").
The most commonly repeated point in the article is "escape hatches bad" and I think that's completely absurd. Of course you want escape hatches, otherwise when you do hit an edgecase you get stuck with no solution. That's exactly what would force you to throw away that approach and pivot. Tailwind doesn't have that problem because it was designed to include escape hatches.
Users deciding to use those escape hatches instead of sticking to a design, isn't Tailwind's fault.
I think what Tailwind actually needs is more abstractions, not to discourage the use of the sole abstraction @apply
There's plenty of ways to manage the bevy of classes you need. First step is making use of components to deduplicate stuff. Then in those components, use a library like class-variance-authority aka "cva()" which allows you to set up complex named presets for your components (like size="small" or color="primary" and things like that).
People that didn't write lines of code on this project, or so.
A few months later, your codebase has very long lines of HTML with classes that encode a whole programming language as strings separated by spaces, and barely no component anymore, nor semantic CSS tags.
Quickly, I realized Tailwind is documented on top on CSS, no way around. This makes you keep in mind both.
No idea why is Tailwind even a thing.
https://x.com/efortis/status/1888304658080256099
The only really critical things I need in scss are scaling typography and variables representing colors for iteratively generating class names and gradients and transparencies and stuff like that. By "scaling typography" I mean, I just have a loop that writes .scaling-typography-[a]-[b] where a and b range from 1 to 16, and the class that's generated scales from [a]em to [b]em between a phone size and a desktop size. In a rare case where that doesn't just work or it doesn't look good on a tablet or something, a couple specific rules extending xs- or sm- or whatever will cover it.
All the mental models required to be good at writing proper stylesheets are trained nicely with Tailwind
For my own projects, I have been perfectly fine with just one large global CSS file, extending it just when I have to. But I could this being maybe tedious when working in a large team.
I never even use tailwind in my own stuff, even though I think that small devoper-led side-projects are where it is a good fit (and the reason for it's popularity).
To be clear, I like css and I find the cascade a great tool, but I also have first hand experienced the pain of too many chefs in the frontend styling kitchen and the havoc that seemingly innocent tweaks here or there can wreak on a site and I prefer tailwind for that reason.
I tend to like simpler/textual interfaces though, admittedly this won't be everyone's cup of tea.
Many people are productive in it, others hate it. Carry on.
15 years and I thought someone would have by now the neat syntax that Qml has.
If anyone knows an alternative, do tell. Very much looking forward to it.
The hilarious thing here is that without JavaScript, the code is white-on-white, because some of the colouring is added on pre[class*="language-"], but the language-css class is only added to the pre element by JS.
I personally started with atomic CSS framework (that was before Tailwind, we had our own) and it has both ups and downs, but overall it is really nice to use once you learn it, and it is not really hard to do so. It does not do anything to enforce variables, but that's why you need to roll either your own layout primitive components or some classes.
I think you mean floor. Floor is a minimum you need. Ceiling would be the maximum you can achieve.
Below this floor you're not useful. There's a ceiling to how much you can do with no code tools.
Centrally the problem is this: large CSS requires a lot of active effort to prevent it becoming spaghetti code.
Writing your own CSS can work in solo projects or small projects but Tailwind was designed for large projects, teams and developers with an irrational fear of CSS.
It always has been css.
That being said, it’s a hard problem and I don’t have a better idea.
Tailwind seems to at least fix or move the problem in the right direction.
I don’t particularly like Tailwind because I know and like CSS. It’s powerful, Tailwild stands in the way of me doing what I want with it. But in this thread you’ll see people saying “it’s great, I haven’t had to learn any CSS in years” and that’s not an invalid viewpoint.
Tailwind is to CSS what React is to the DOM, if not even more so. If you’re working on a ton of boilerplate UI it lets you get the job done without having to learn the core technology being used. For better or worse that’s where the industry is today.
All I would say is that solely Tailwild folks owe it to themselves to look at modern CSS sometime. The arrival of variables in particular is a gamechanger and makes things like palettes and theming far more intuitive than it ever used to be. When I see how Tailwind handles dark mode I cringe. With raw CSS you set a color palette as variables then override them with a media query. The element itself doesn’t need to have anything added.
My global tailwind.css defines two sets of css vars for the light and dark theme, and it all gets applied globally with a single line in my root html template. I don’t need to touch my markup. Tailwind simply compiles this down to a single css file in the end.
It did give me some ideas for my own stylesheet writing though. The colorsystem is something even non-tailwind projects will have now.
And how did plain css solve that? You're mixing up a few issues there.
It didn't work in practice, because people want to structure their document based on how they expect it to be presented.
My understanding is thay HTML5 was built on the understanding that language purity just went in the way of productive compromise.
While I don’t really have a strong opinion on Tailwind CSS, I do have a strong negative reaction to websites who advertise to everyone how many people are on the page, especially when that’s shoved in our faces and people can send malware links and spam to everyone else (as is happening in droves).
Cute idea, but it is pretty clear the author doesn't consider practical consequences, so why should I trust their judgement about Tailwind?
Generally coupled by some memory leaking React soup, solving 2016 SPA problems in 2026.
Likely 30-something years old MIT-bred leetcode ninjas that know little to nothing about front end technologies in the first place. They don't even remember _why_ the industry reached for client-side rendering library at some point. They think it's for interactivity. HN comments are quite telling about it.
Bloated slop is bloated slop, I still have to find a single example proving me wrong, and what's produced on top of react-tailwind by billion dollar companies just confirms my negative bias around the people using it, the results speak for themselves.