This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work. Over years. You can onboard new developers to it, able to contribute productively immediately. Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works.
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:
<p class="text-red-500 text-green-500">I am some text</p>
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`.
I've never found tailwind to help someone who isn't already a reasonably skilled web developer. If you don't know CSS tailwind gets your far enough sometimes, but you have to learn many of the same paradigms as you would in CSS and you can still create issues that aren't as simple as missing "text-green-500".
Tailwind seems most useful for devs who don't want to be responsible for managing multiple CSS files and all the naming conventions that come along with it. They're basically looking for using inline styles after having likely heard for a long time to not use the style tag.
For me at least, any value from tailwind went out the window when frameworks started leaning into single file components and scoped styles. I keep components small enough that generally my style selectors are only using element and attribute selectors, I dodge the class naming issue entirely and still get to use CSS instead of inline styles.
> If you end up programmatically layering class names, you're looking at a code smell.
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?
There is this implicit debate in web application development of cascading+overriding vs non-cascading-no-overriding. A lot of people don't even realize this is where the line is drawn and mix both together. I call them "component-based", "document-based" and "mixed".
Component-based applications are usually better of with no styling cascading and no styling overriding. It makes things significantly easier because components are self contained and don't change in appearance based on styling of parent-elements on the tree (besides physical dimensions available and transparency effects of course).
Document-based applications are usually better of with cascading and overriding. Although no-cascading-no-overriding can work too, but requires more code.
Component-based is quite difficult to do without some tooling (like tailwind or css-modules, etc). Most CSS tooling support both though.
Tailwind implicitly forces you into the component-based paradigm but never explains it properly. There is a reason why people who love tailwind say it just makes things much more manageable. It is mostly because it removes the "mixed" mode that projects silently fall into[1] unless there is some guiding force towards component-based.
However component-based approach is quite doable with many different CSS solutions. Tailwind just _forces_ you into it.
For example CSS-modules component-based just means one .css file per component with only .className {} CSS selectors and not relying on cascading values from above in the tree (a few global rules can solve this).
[1]: Mixed mode as I call it is mixing hyper-local rules with cascading rules. They fall into this mode because that is how plain CSS works without extra tooling and guidelines.
author of the article is making a logical argument - in matters of human behavior. that never works.
author should've instead asked himself & the world - why people are drawn to tailwind. yeah technically it's inferior - but in terms of being optimized for how people do things - tailwind is superior.
I can see this argument both ways. On the one hand, logically you'd expect the last assignment to take precedence, like the style attribute. On the other, conflicting styles don't make sense.
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.
It’s random sure, but it’s also reliably random. This is one of the few footguns that exist in tailwind and luckily it’s super easy to catch. The IDE plugins will give you a warning if you apply multiple classes that manipulate the same attribute and there is no reason you also can’t catch it in CI.
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.
Sometimes true, but one issue here is that because Tailwind utility classes vary from being a 1:1 mapping to a single underlying style rule, to mapping to several, it's not always obvious which classes will conflict.
I wouldn't even write such a class name. It smells like bad styling and layouting already. A CSS class should convey some semantic meaning. I would name it after the thing that should be red or green, not "red"/"green". That doesn't tell me anything. Maybe its name could be something like "danger" or "active" or something. Also the 500 looks very sus. Responsive design is best when it avoids such hardcoded numbers and depends on its content and dynamic viewport width calculations, and perhaps a few minimum sizes, if necessary to decide when things float, wrap, shrink, grow, etc.
Absolutely not. Semantic classes are the wrong way to go. Your components (and their props API) are what encode the semantics. With Tailwind you never need to try to come up with a name for anything relating to style, you just use utility classes. It reduces cognitive load significantly.
The fact that “text-red-500 text-green-500” resolves by stylesheet source order rather than anything visible in the markup means the “locality of behavior” promise quietly breaks exactly when you compose components dynamically, which is why tailwind-merge exists at all, and needing a runtime dependency to answer “which of my two classes wins?” is a real design smell, not a bikeshed.
That is kind of my point, though—you don't need tailwind-merge, really. There are two cases it solves:
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:
It's not true - agents will visibly struggle more with worse code bases. If anything, certain kind of maintainability matters more in this era, than before, because it is so much cheaper to just generate a huge amount of low quality code.
Author: "In my vanilla CSS, I can read it in the CSS file. In Tailwind, who knows?!?"
Reality: You read it from location 2, not from location 1. The horror.
I don't even have a dog in the race. I'm past my days of handcrafting HTML and CSS. I have a few Claude Coded apps that use Tailwind, but I've not looked at any of the files (yes yes, I know. They're personal projects that run in my homelab. I don't care.)
they do work… for any value of work. I have been in the industry for a while, and I've never seen a project which doesn't slowly devolve into fights with the cascade over time - arbitrary abstraction layers, ad-hoc organization patterns, developer-specific conventions, inconsistent naming, and so on. All of this usually creeps in the more a project grows. At some point, someone adds postcss or scss or another preprocessor and starts splitting files, and then a whole new set of new, made-as-you-go conventions comes in: Files per component or per view? Or rather per architecture concern? Usually a mix of them. As files are split, the class naming gets even more inconsistent.
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.
> Out of curiosity how long have you been doing frontend development?
I've been writing CSS since IE 6 and I can tell you not a lot of us oldies like tailwind. I've only seen a strong inclination towards Tailwind from the newer generation frontends (2015 and beyond)
Us oldies actually prefer BEM over anything else.
My talking point is based off internal comms from a large'ish company (200+ FE devs) so YMMV
Many of us oldies who started working on the web years before IE 6 actually like Tailwind. We all have our preferences. But I know multiple 50+ year olds who have been doing this work since CSS was barely a proposal who now use Tailwind.
Tailwind trades cascade complexity for design drift when working across teams. You can’t ignore that it encourages a different kind of undisciplined sloppiness.
Would I take it over the 1000 line cascade problems? Probably, but I’d still prefer css modules over tailwind.
I see you have a .button, cool! So did you load the entire context of your project into your mind, and calculate every possible iteration of kind, size, color etc this button may have? And once you did that, did you come up with a semantically correct naming scheme that is clear and will not succumb to the inevitable .button_checkout_special_page_cta_widget a particular page will end up requiring?
No? Neither did I. I stopped thinking about CSS entirely almost a decade ago. Thanks Tailwind.
It’s funny, as someone that’s been using CSS for decades I don’t really know how to respond because the scenario outlined here is not one I recognise. My button would be a <button>, so no, I wouldn’t have a .button class, it’s superfluous.
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?
You just make a design system in your tailwind.css, following the documentation. You can optionally use something like daisyui if you do not have designer skills or the time.
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.
We are stuck with CSS, but all these CSS styling frameworks just tell me CSS needs to be bulldozed. I looked up DaisyUI that you mentioned. The example on the home page gets rid of chained classes and replaces them with one:
// Styling a simple button
<button class="btn">
daisyUI Button
</button>
It's a utility to generate deduped/treeshacken css classes - according to a config file the parent mentioned
It's not some grand framework or something.
It's literally doing exactly what the grand parent said. Define root css variables, and generate the applicable/used css classes that were used in the code
I use Tailwind for work and hobby projects and what you said is exactly what I think Tailwind is and why I use it.
I don’t understand where the disagreement is. I was only pointing out a lot of the “magic” from Tailwind’s abstraction isn’t as magical as the GP you referred to implies.
The poster I responded to, specifically asked for how to implement this in tailwind, with a worry about "do you really style each component separately for dark mode? Repeating the same modifiers over and over?"
I simply answered his question - tailwind is indeed just plain old CSS with a more ergonomic DX.
Are you suggesting to style the tag name directly? Because that would create chaos in a codebase. <button> is for semantics. It's possible that other design system components need the same semantic element.
No, I’m suggesting that .button.something-else wouldn’t make any sense. You’d just do button.something-else… not that it would really be that useful to do so.
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.
You still have to remember what sizes or whatever to use for what to make it consistent, it’s just they get packed into the “class” attribute. It’s not uncommon to see very long class attribute lines with tailwind with all kinds of p-this and mx-that or whatever. I’ve also seen quite a lot of p-[whatever] tags, at which point all the consistency goes out the window.
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)
Don’t you need to keep more context in your mind if you use Tailwaind to make .button_checkout_special_page_cta_widget while staying somewhat consistent?
Could you give us a few examples with and without Tailwind, including CSS variable and compose in preprocessors?
I know what you mean. But somehow that doesn't bother me. In fact it forces me to think about consistency of the design and often makes me think of a more general schema and simplifications in styling, or getting rid of something too specific/special.
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.
CSS for design systems is fine. You can define a .button[data-variant=”primary”]. It’s intuitive, performant, makes sense.
CSS for application code is terrible — specifically layout & typography. The different kinds of flex/grid layouts are tightly coupled to the dom structure. Tailwind is a great fit here:
When you remove layouting concerns and maybe typography. You actually get close to the separation of concerns that CSS was initially aiming for. HTML determines arrangement and css determines the design system (colors, borders, shadows etc...).
For a very long time now I've avoided anything other than 1 class per div with style overrides and written with modular rules and 1-2 degrees of separation between label and rules.
This has the advantage of being naturally rule based and amazingly succinct to write and understand. Needless to say I'm an odd duck, since I almost never see css written this way.
Tailwind looks bad on "paper". It violates a lot of "best practices". It is ugly. Yet in reality it works. It gets the job done. It is fast to work with.
My constraint is "use vanilla CSS" ;) I made a huge solo project in tailwind. Never again. Vanilla CSS is perfectly fine for my own uses. In fact, I've gone a whole 'no classes' style and used as much semantic HTML and modern CSS and can get extremely far. No more looking into the tailwind docs to learn its syntax on a modern vanilla CSS feature that I've been waiting for.
IMO this is one of those things where theory meets practice. Theoretical coders (i.e. those who love the code itself, rather than how well it works for the end user) tend to hate on Tailwind, while those who prioritize end user value over code perfection tend to like Tailwind.
I was very much in the Tailwind camp, and simultaneously loved it for its local reasoning and disliked it for how its long class names messed up my components. It has always felt like a bolted-on hack to me but I couldn't argue with the benefits.
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.
What is funny with your article is that you talk about tradition, when actually these traditions are based on assumptions which are themselves based on beliefs like : "separation of structure and style are a good thing".
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, ...).
I don't recommend css. Css is BLOATED. And tailwind makes it a little less bloated, but it's still not strongly typed, and not very re-usable, especially in code.
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 ;)
Saying "unless you use @apply" invalidates this article for me. Everyone knows that @apply only exists as an escape hatch, it is not supposed to be used, except for when it's necessary like for compatibility with libraries that declare their own classes that you need to override.
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.
It makes no sense for me that @apply is frowned upon. It's what makes Tailwind actually kinda usable for me. Without it, markup looks like line noise full of boilerplate that's hard to modify in a systematic way.
I think what Tailwind actually needs is more abstractions, not to discourage the use of the sole abstraction @apply
Using @apply defeats the entire purpose of Tailwind. The point of it is to localize styling alongside the markup. If you're using @apply then you're constantly context switching from your markup to your CSS files while working.
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).
I use @apply in quite a few projects, mainly because I like the defaults in tailwindcss. I know it defeats the point of tailwind, but I find that it works nicely when using BEM.
I genuinely don't understand, why would you use `@apply text-center` instead of `text-align: center`?
Like if you're already at the point of setting up stylesheets & classes with a pre-processor why would you do that and not say use scss with some mixins for the more complex reused parts? At that point any IDE plugin that knows CSS can give you completion and your compiled sources will look a lot like the written ones in the dev tools.
Personally I wouldn't use `@apply text-center` over just `text-aligh: center;`, but I do use `@apply text-red-300` or `@apply px-2`, simply because I like the set of defaults Tailwind comes with.
I tried building my own set of defaults, but eventually decided that just using the Tailwind ones is much easier.
Show me one non-trivial project with classic, well-organized CSS usage and clean semantic HTML.
It just never works out. There were attempts like BEM, which looks promising at first sight but is awkward at some points and only works if all devs strictly follow the convention. We all know how this usually works out. I once was that semantic HTML and css classes guy too, I completely changed my mind. In the end, we want to efficiently build a clean and shiny website. No real user looks into the (unminified) HTML source code to appreciate those awesome, sophisticated semantic CSS classes.
I tried to use Tailwind in a hobby project couple years ago. I havn't updated my CSS skills since 2010 or 2015 -- I certainly missed grid layout and some other new features.
Quickly, I realized Tailwind is documented on top on CSS, no way around. This makes you keep in mind both.
This is written from a point of view of somebody who never went through the progression of CSS to CSS preprocessors to component-based frontend libraries. Tailwind is an answer to all the problems that become apparent in CSS in that progression.
Right so it is easier to write code quickly, but not to maintain a system. Tailwind is the right tool if you want to generate a prototype with LLM agents. It can be quickly deleted or can be used as visual prototype to create reusable components. And once the component is built for long term maintenance as priority, the collective knowledge has been built up so naming becomes simpler, important and elucidating.
The component itself is the semantics, adding naming over CSS classes adds no value whatsoever, only adds cognitive load and requirement of context switching to understand "what does this named class actually do?"
What's so strange with Tailwind users is how insistent they are to impose it to codebases they don't know. I've never seen this even with vue vs react.
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.
Your complaint is about bad developers, not about Tailwind. Using Tailwind correctly means making heavy use of components to avoid duplication. Using Tailwind also removes the burden of having to do one of the hardest things in software: naming things, which is what semantic classes requires you to do.
I'm not a frontend guy so take this with a pinch of salt, but for a few personal projects I've done my approach is now "ai pls generate css". I thought it would be inconsistent and broken, but if you tell it to care about accessibility and you're willing to clean up a bit it's not that bad and you end up with very compact transfers after minification.
I tend to like simpler/textual interfaces though, admittedly this won't be everyone's cup of tea.
I've used a lot of tailwind professionally over the last few years and I agree with this article - it is spot on.
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).
I have the opposite experience regarding where it’s useful. In large teams , using an atomic css framework provides good guard rails and predictable behavior. I can confidently copy a marketing page or some random thing on the other side of the company and with very minimal tweaking, it will probably work. With normal CSS, the cascade is much more likely to cause subtle shifts in behavior over time as the main stylesheet is extended and modified.
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.
Using @apply totally KILLS Tailwind - that's the clearest tell that the author didn't have that moment yet. Hence the other arguments in the article that feel somewhat petty.
God help me, somewhere around 2016 I started using some alpha version of Bootstrap 4, and I just keep using that same version for all the basic stuff underneath my own SCSS for whatever I'm building. It's absolutely fine. A lot of it is displaced now by grids, but for flexbox stuff and modals and pushing rows and columns it just works. Very easy to remember class names and extend it. Thankfully I don't work for a company that cares about using the latest thing.
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.
Ergonomics for hand composition are less relevant now. The most important trait is how does a long-lived project perform when written by a coding agent.
I’m curious if anyone has any takes on the different approaches to agentic styling.
I’ve tried Tailwind for this without further steering, and after a while the agent starts adding unnecessary utility classes everywhere. Then I taught it to micro-Ralph eval all its utility classes using screenshots and this works ok but burns a lot of tokens. Treats the symptom and not the problem IMO.
Maybe with the right set of constraints there’s a subset of Tailwind that composes better? I went back to vanilla CSS for now, on the hope that it will readily port to whatever the best thing ends up being later.
My (certainly not unique) take is: As with almost everything, choose what you use based on context. There is a very wide range of websites and web applications you can make. For some of those tailwind is a good fit. For many it is not.
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.
> It breaks the separation between structure and design
I have a problem with this argument because CSS _itself_ breaks that separation.
`border: 1px solid red;` is design, but `display: flex;` is structure.
In my opinion, it makes sense for display properties to live in the HTML because they are by their very nature very tighly coupled to the markup.
Though I appreciate that making this distinction creates a separate problem of your team having to exercise good judgement (and consistency) in which CSS belongs where.
Tailwind didn't happen by chance - it was the culmination of many other failed philosophies for addressing a problem with CSS when it gets large.
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.
After trying a Tailwind-adjacent library myself (UnoCSS) I came to the conclusion that it's awful, but it's the least awful among worse alternatives. Having gone through BEM, I have no desire to go back there. Layers, modules, and scoped CSS seem like they could address a lot of the pain points in semantic CSS that TW was trying to, but I've never used any of those in anger save for Vue's emulation of scoped CSS.
IDEs can autocomplete tailwind classes but eventually you just memorize them, also with AI assisted coding I don't even write the classes anymore just small adjustments like changing pt-3 to pt-4, AI implemented dark mode in a small app I am working on in one shot, I think tailwind being in the training data helped tremendously with the task.
Coming from Qml, reading css/html is mind numbingly hard.. Haven't seen any other come even remotely close to the readability of Qml. I am talking generic UI development, not just for browsers.
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.
Using them perhaps? Complaining about separation of concerns never makes any sense when you use components because the components are the structure and the styles are tightly coupled. You could separate the styles, almost all of them are going to be specific to the component so there's not much of a point unless you really like writing one-off class names.
In my opinion, the main problem with Tailwind is that it attempts to replace all CSS. Tailwind classes are often non-semantic and don't align well with CSS property names. Where pure CSS can be used, the code will be cleaner and more readable. It's important to remember that HTML has a "style" attribute, and it's often much easier to define a style block directly in the "style" attribute than to use a fragment and Tailwind's cumbersome CSS classes.
This discussion again. We've been having it for 6 years now and Tailwind remains popular. Lindy's Law tells us it will remain popular for a while longer.
Many people are productive in it, others hate it. Carry on.
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.
The argument basically boils down that in non-component approach (so not a modern web framework) it is harder to reason if you use tailwind classes. The rest is some serious bikeshedding, imo.
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.
My personal experience (for what it's worth): I've used Tailwind across various project of different sizes for about one year then simply stopped using it. I just don't see any real advantage to use it over regular CSS.
Every technology is going to have a problem, if you install something new, you'll have to discover the problems, if you use the standard tech stack, you will know exactly what the problems are.
Honestly, I found managing a Bulma codebase significantly more of a pain in the ass than Tailwind. Tailwind offers the expressiveness of actual CSS with the ability to make quick changes on the fly. As someone who has spent a lot of time working in CSS frameworks over the years, it is one of the better abstractions of its kind.
I sort of feel like this argument is trying to put a train that is already halfway across the country back in the station on the East Coast.
I switched from Tailwind to plain CSS with a UI library and it honestly made my site look better. Probably because it's much harder to spam backdrop effects.
Pre-llm era Tailwind was great for the backend people who did not want to learn CSS. Nowadays agents got this. Openprops might be a good option even with agents, at least for me it works well. Not a surprise that Tailwind popularity dropped significantly.
I think the another llm-victim is React. For a while it was great to have a heavy framework that somewhat standardised webdev's JS approach. Astro just become the default goto lightweight option that is great to quickly build a nice simple UI.
I’d be rather interested in a recommandation that don’t comes with de usuals pits of others solutions and comes with a the actual css code that will apply to the element displayed in autocomplete while editing the html / jsx.
Not a big fan of vanilla tailwindcss too, but (from the perspective of someone that needs the job done) "just use modern CSS" as the author suggest is even worse.
Honestly I tire of this debate. Both sides have good points have both choices are valid.
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.
That’s exactly how I’m doing this using tailwind and daisyui though, so I’m not sure what point you are trying to make?
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’s funny how, upon opening the website, you’re immediately greeted with a “Was Top 1 on Hacker News” link leading back here, but (at time of writing) it has under 50 points and almost every comment disagrees with the post.
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).
People tend to overlook the main benefit of Tailwind: components and pages become self-contained. As such, changing them doesn't cause unintended side-effects to other pages and all or parts of a component can be dropped into another page and it "just works." This is a huge benefit as the normative/intended behavior of CSS makes changes risky on large sites. Now, there are other ways to do this, but Tailwind is quite effective at it.
My theory is that higher-level abstractions don't need to add any value to be popular, you can just create a single dependency that abstracts away one lower level dep, and people will use it only because they want to avoid learning something, in the end they will actually learn the thing with a proxy in the middle, but at least they took a shot at skipping the 'grind' of learning css.
I know complaining about the site is poor form, but it is really hard to take advice seriously for a site that lets other visitors spam... just general internet things to other visitors.
Cute idea, but it is pretty clear the author doesn't consider practical consequences, so why should I trust their judgement about Tailwind?
I can immediately spot organizations void of any skilled frontend engineering leadership by their use of 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.
Straight from my heart - i couldn't have said it better. I always had this answer in my head, but nobody asked and it felt senseless to talk about unpopular opinions. Now you have been faster than me, here under the umbrella of the tailwind-topic - but you should know, you are not alone with exactly that attitude.
My sass customers don't even know what css means, it's fine. Nobody cares as long as the things they expect are on the page in the right position and font is readable.
They don’t, unfortunately. Any time I bring up the wonders of Elixir/Erlang or how great Postgres is, their eyes glaze over unless they have some kind of technical background. I’ve had many conversations where people were surprised there’s more than one programming language, they assume it’s some sort of 1s and 0s that flash past the screen Hollywood style.
I registered my first domain 1997 and before that already coded websites: members.aol.com/…/
I saw the inception of CSS, the infamous ACID test, IE6, web standards movement - anything and everything.
To this day, CSS is something that is not separating design from markup (try logic, you will get it), and as all things technology is now a mix of technical constraints, backwards compatibility, totally conflicting decisions.
I am traumatized with floats and clearfix, and there was a lot of debate around CSS 3, JavaScript.
Layout wise, “the web” aka web traditionalists or whatever went bezerk against any attempts to allow for what today is dominating: print layout as role model.
Formerly flow was all about responsive web design, being as fluid as it gets.
CanIUse had to be brought to life to solve the questions, what features needed to be done in JavaScripts, which not.
Stylus, BEM, bootstrap, SCSS etc.
All kind of conventions and preprocessing helpers.
CSS is hard and will stay hard, in fact I am stunned by the author’s total ignorance of where CSS came from, why something is the way it is.
Maybe he is just a young gun and thinks that CSS is only flow, grid and CSS3 and always waiting for cool new features which do what? What purpose do they have, which problem do they solve?
Tailwind is genius. There is pro and con for everything but looking back it is just another evolutionary step on the shoulder of the mentioned giants.
To this day no framework or system was more simple and elegant than Tailwind.
Tailwind is shadowing native CSS functionality? I felt pain reading this because so what? That”s not the point.
We use preprocessors, postprocessors, optimizers - what I don’t want to do is using CSS’s own bad naming nomenclature which is used because of backwards compatibility.
In fact abstracting away basic functionality and simply let the compiler decide what is best given the situation is mentally helpful.
Working in large teams, or many teams. Guess what will happen: we build our own CSS framework, well we build ten because everyone knows best.
The author really should be thankful for the genius job Tailwind does, because he seems extremely inexperienced and never faced hard challenges.
In fact if your only problem is to decide between two frameworks, you are lazy and not considering other people.
Browser compatibility, breaking changes, different CSS as well as JavaScript engines - this was brutal.
Today? Luxury discussions.
The fact that Tailwind allowed for a gazillion of partly stunning CSS design systems and React components like ShadCN and others is proof enough that Tailwind is a platform with the best pro/con ratio so far.
This has never been the case before. This is a singularity.
I was founder and product lead for a huge and critical to business financial platform, seeing others easily augmenting your platform via interfaces or plugin patterns as a structured approach is genius.
Extensibility is a sign of elegance and perfect abstraction.
Are there downsides? Who cares with all these never seen before massive benefits?
The killer against laissez fair CSS is exactly this: have you ever lead an approach to develop a framework? Why do you want to build yet another TW?
Drop it. It won’t work. The question or better your solution hints at being a solo dev.
This is fine but you seem so one sided in your views, I am puzzled.
If I could use just native CSS boy oh boy - do you really know everything about it? Could you understand a floating layout? Could you see pro and contra for its use case or do you just not allow its usage? If yes, why if you cannot answer the question?
How do you make sure, there is standardization? How do you train and coach people so that they know and can use CSS?
What are your naming conventions? Why this way, no other way?
How do you deal with devs leaving, new joiners?
Who is overseeing the repository? Who has merge rights? Who does the code reviews?
What do you do if there was an emergency and some big shot or very important order had to be accommodated and now you have garbage CSS in your platform that you must maintain and everyone can use?
Boy oh boy - I love Tailwind. The versatile solution that was 30 years in the making.
All you delusional freaks out there with the hubris belief: tell me how it went.
I just covered a few questions. Deployment is yet to debate etc.
This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work. Over years. You can onboard new developers to it, able to contribute productively immediately. Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works.
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`.I've never found tailwind to help someone who isn't already a reasonably skilled web developer. If you don't know CSS tailwind gets your far enough sometimes, but you have to learn many of the same paradigms as you would in CSS and you can still create issues that aren't as simple as missing "text-green-500".
Tailwind seems most useful for devs who don't want to be responsible for managing multiple CSS files and all the naming conventions that come along with it. They're basically looking for using inline styles after having likely heard for a long time to not use the style tag.
For me at least, any value from tailwind went out the window when frameworks started leaning into single file components and scoped styles. I keep components small enough that generally my style selectors are only using element and attribute selectors, I dodge the class naming issue entirely and still get to use CSS instead of inline styles.
> If you end up programmatically layering class names, you're looking at a code smell.
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?
There is this implicit debate in web application development of cascading+overriding vs non-cascading-no-overriding. A lot of people don't even realize this is where the line is drawn and mix both together. I call them "component-based", "document-based" and "mixed".
Component-based applications are usually better of with no styling cascading and no styling overriding. It makes things significantly easier because components are self contained and don't change in appearance based on styling of parent-elements on the tree (besides physical dimensions available and transparency effects of course).
Document-based applications are usually better of with cascading and overriding. Although no-cascading-no-overriding can work too, but requires more code.
Component-based is quite difficult to do without some tooling (like tailwind or css-modules, etc). Most CSS tooling support both though.
Tailwind implicitly forces you into the component-based paradigm but never explains it properly. There is a reason why people who love tailwind say it just makes things much more manageable. It is mostly because it removes the "mixed" mode that projects silently fall into[1] unless there is some guiding force towards component-based.
However component-based approach is quite doable with many different CSS solutions. Tailwind just _forces_ you into it.
For example CSS-modules component-based just means one .css file per component with only .className {} CSS selectors and not relying on cascading values from above in the tree (a few global rules can solve this).
[1]: Mixed mode as I call it is mixing hyper-local rules with cascading rules. They fall into this mode because that is how plain CSS works without extra tooling and guidelines.
author of the article is making a logical argument - in matters of human behavior. that never works.
author should've instead asked himself & the world - why people are drawn to tailwind. yeah technically it's inferior - but in terms of being optimized for how people do things - tailwind is superior.
I can see this argument both ways. On the one hand, logically you'd expect the last assignment to take precedence, like the style attribute. On the other, conflicting styles don't make sense.
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.
It’s random sure, but it’s also reliably random. This is one of the few footguns that exist in tailwind and luckily it’s super easy to catch. The IDE plugins will give you a warning if you apply multiple classes that manipulate the same attribute and there is no reason you also can’t catch it in CI.
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.
> conflicting styles don't make sense
Sometimes true, but one issue here is that because Tailwind utility classes vary from being a 1:1 mapping to a single underlying style rule, to mapping to several, it's not always obvious which classes will conflict.
I wouldn't even write such a class name. It smells like bad styling and layouting already. A CSS class should convey some semantic meaning. I would name it after the thing that should be red or green, not "red"/"green". That doesn't tell me anything. Maybe its name could be something like "danger" or "active" or something. Also the 500 looks very sus. Responsive design is best when it avoids such hardcoded numbers and depends on its content and dynamic viewport width calculations, and perhaps a few minimum sizes, if necessary to decide when things float, wrap, shrink, grow, etc.
It's a red flag (ha).
Absolutely not. Semantic classes are the wrong way to go. Your components (and their props API) are what encode the semantics. With Tailwind you never need to try to come up with a name for anything relating to style, you just use utility classes. It reduces cognitive load significantly.
And so we’re essentially back to <font color=red size=10>?
The fact that “text-red-500 text-green-500” resolves by stylesheet source order rather than anything visible in the markup means the “locality of behavior” promise quietly breaks exactly when you compose components dynamically, which is why tailwind-merge exists at all, and needing a runtime dependency to answer “which of my two classes wins?” is a real design smell, not a bikeshed.
That is kind of my point, though—you don't need tailwind-merge, really. There are two cases it solves:
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.I would reach for class-variance-authority (aka cva) instead for stuff like a size prop, it declaratively solves that.
Interesting, I didn't know that project yet! I'll give it a thorough read.
It's not true - agents will visibly struggle more with worse code bases. If anything, certain kind of maintainability matters more in this era, than before, because it is so much cheaper to just generate a huge amount of low quality code.
I agree that all of this is bikeshedding, but the cascade complaint is actually real.
It's so common, that there is an expensive runtime package, `tailwind-merge`, that is used by default in the most popular component library.
also note that `class="text-red-500 text-green-500"` gets flagged immediately by the Tailwind VS Code plugin
> 'text-green-500' applies the same CSS properties as 'text-red-500'. tailwindcss(cssConflict)
So even if you do it by accident, it will tell you.
The "rounding" was grasping at straws:
> How round is rounded-lg?
Author: "In my vanilla CSS, I can read it in the CSS file. In Tailwind, who knows?!?"
Reality: You read it from location 2, not from location 1. The horror.
I don't even have a dog in the race. I'm past my days of handcrafting HTML and CSS. I have a few Claude Coded apps that use Tailwind, but I've not looked at any of the files (yes yes, I know. They're personal projects that run in my homelab. I don't care.)
> You can onboard new developers to it, able to contribute productively immediately
Maybe it helps with people nee to Web development but as an existing CSS developer tailwind slows me down incredibly.
I know exactly what styling I wish to apply, I now have to translate it into another language to apply it.
And the browser inspector looks terrible because every element has a long bunch of utility classes added to it.
Projects with a single gigantic CSS file also work and you can onboard people etc. That's not an argument.
they do work… for any value of work. I have been in the industry for a while, and I've never seen a project which doesn't slowly devolve into fights with the cascade over time - arbitrary abstraction layers, ad-hoc organization patterns, developer-specific conventions, inconsistent naming, and so on. All of this usually creeps in the more a project grows. At some point, someone adds postcss or scss or another preprocessor and starts splitting files, and then a whole new set of new, made-as-you-go conventions comes in: Files per component or per view? Or rather per architecture concern? Usually a mix of them. As files are split, the class naming gets even more inconsistent.
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.
> I have been in the industry for a while
> Out of curiosity how long have you been doing frontend development?
I've been writing CSS since IE 6 and I can tell you not a lot of us oldies like tailwind. I've only seen a strong inclination towards Tailwind from the newer generation frontends (2015 and beyond)
Us oldies actually prefer BEM over anything else.
My talking point is based off internal comms from a large'ish company (200+ FE devs) so YMMV
Many of us oldies who started working on the web years before IE 6 actually like Tailwind. We all have our preferences. But I know multiple 50+ year olds who have been doing this work since CSS was barely a proposal who now use Tailwind.
Tailwind trades cascade complexity for design drift when working across teams. You can’t ignore that it encourages a different kind of undisciplined sloppiness.
Would I take it over the 1000 line cascade problems? Probably, but I’d still prefer css modules over tailwind.
I see you have a .button, cool! So did you load the entire context of your project into your mind, and calculate every possible iteration of kind, size, color etc this button may have? And once you did that, did you come up with a semantically correct naming scheme that is clear and will not succumb to the inevitable .button_checkout_special_page_cta_widget a particular page will end up requiring?
No? Neither did I. I stopped thinking about CSS entirely almost a decade ago. Thanks Tailwind.
It’s funny, as someone that’s been using CSS for decades I don’t really know how to respond because the scenario outlined here is not one I recognise. My button would be a <button>, so no, I wouldn’t have a .button class, it’s superfluous.
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?
You just make a design system in your tailwind.css, following the documentation. You can optionally use something like daisyui if you do not have designer skills or the time.
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.
We are stuck with CSS, but all these CSS styling frameworks just tell me CSS needs to be bulldozed. I looked up DaisyUI that you mentioned. The example on the home page gets rid of chained classes and replaces them with one:
// Styling a simple button <button class="btn"> daisyUI Button </button>
So, we are back to regular CSS?
Almost none of that is specific to Tailwind though, you can take any design system in CSS with or without JS and make the same argument right?
What do you think tailwind is?
It's a utility to generate deduped/treeshacken css classes - according to a config file the parent mentioned
It's not some grand framework or something.
It's literally doing exactly what the grand parent said. Define root css variables, and generate the applicable/used css classes that were used in the code
I use Tailwind for work and hobby projects and what you said is exactly what I think Tailwind is and why I use it.
I don’t understand where the disagreement is. I was only pointing out a lot of the “magic” from Tailwind’s abstraction isn’t as magical as the GP you referred to implies.
I see, I must've misunderstood your comment earlier.
The poster I responded to, specifically asked for how to implement this in tailwind, with a worry about "do you really style each component separately for dark mode? Repeating the same modifiers over and over?"
I simply answered his question - tailwind is indeed just plain old CSS with a more ergonomic DX.
Congratulations, you reinvented regular CSS.
If that is so, why are people getting up in arms about tailwind?
If it's just CSS then why would I use Tailwind instead of the actual thing? It's a layer of indirection for no reason if it's the same.
If BEM is regular CSS, why would I use BEM instead of the actual thing? It's a layer of indirection for no reason if it's the same.
You use Tailwind in the same way you use BEM: becuase it makes it easier for frontend developers to write correct CSS.
You're right which is why I don't use BEM, it has no advantages over regular CSS, same with Tailwind.
Are you suggesting to style the tag name directly? Because that would create chaos in a codebase. <button> is for semantics. It's possible that other design system components need the same semantic element.
No, I’m suggesting that .button.something-else wouldn’t make any sense. You’d just do button.something-else… not that it would really be that useful to do so.
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.
I feel like scoped css and component libraries fixed this issue. I don’t have a .button, I just have a <Button> that has all its css self contained.
And just a shared color definition file.
Same, my need for tailwind got completely ridden when I started using Svelte, thanks to the CSS-scoping it entailed.
That's funny, Vue had this like a decade ago. It was nice but I switched to React instead due to library support.
And @scope does this for all of css.
You still have to remember what sizes or whatever to use for what to make it consistent, it’s just they get packed into the “class” attribute. It’s not uncommon to see very long class attribute lines with tailwind with all kinds of p-this and mx-that or whatever. I’ve also seen quite a lot of p-[whatever] tags, at which point all the consistency goes out the window.
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)
Yes. Bootstrap and all other CSS frameworks before Tailwind did it, too.
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.
Don’t you need to keep more context in your mind if you use Tailwaind to make .button_checkout_special_page_cta_widget while staying somewhat consistent?
Could you give us a few examples with and without Tailwind, including CSS variable and compose in preprocessors?
I know what you mean. But somehow that doesn't bother me. In fact it forces me to think about consistency of the design and often makes me think of a more general schema and simplifications in styling, or getting rid of something too specific/special.
And did you remember to include the exact same Tailwind classes with every instance of your button in your project?
Yes.
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.
What? I don't even know what you're talking about, and I've written mountains of vanilla CSS code in big projects.
We need to talk about two use-cases separately:
CSS for design systems is fine. You can define a .button[data-variant=”primary”]. It’s intuitive, performant, makes sense.
CSS for application code is terrible — specifically layout & typography. The different kinds of flex/grid layouts are tightly coupled to the dom structure. Tailwind is a great fit here:
When you remove layouting concerns and maybe typography. You actually get close to the separation of concerns that CSS was initially aiming for. HTML determines arrangement and css determines the design system (colors, borders, shadows etc...).I havent seen this discussed a lot. The old Radix team had a short note: https://www.radix-ui.com/blog/themes-3#the-best-of-both-worl...
For a very long time now I've avoided anything other than 1 class per div with style overrides and written with modular rules and 1-2 degrees of separation between label and rules.
Something like
.title {
}This has the advantage of being naturally rule based and amazingly succinct to write and understand. Needless to say I'm an odd duck, since I almost never see css written this way.
(edit: I forgot how to format code on HN)
As a 26+ year frontender, years ago I was against it on so many levels. Until I tried it.
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.
Tailwind looks bad on "paper". It violates a lot of "best practices". It is ugly. Yet in reality it works. It gets the job done. It is fast to work with.
Constraints are known to enhance creativity.
My constraint is "use vanilla CSS" ;) I made a huge solo project in tailwind. Never again. Vanilla CSS is perfectly fine for my own uses. In fact, I've gone a whole 'no classes' style and used as much semantic HTML and modern CSS and can get extremely far. No more looking into the tailwind docs to learn its syntax on a modern vanilla CSS feature that I've been waiting for.
IMO this is one of those things where theory meets practice. Theoretical coders (i.e. those who love the code itself, rather than how well it works for the end user) tend to hate on Tailwind, while those who prioritize end user value over code perfection tend to like Tailwind.
Semantic CSS is Java AbstractBeanFactoryBuilder. Or as Steve Yegge put it, Kingdom of Nouns.
Tailwind CSS is Python dictionaries where you don't create one user-order-deliver-date CSS class for every Noun you have.
Totally agree. It does break the rules, but it feels so much faster than defining class names.
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.
I felt the same way with JSX. Started using it and don't want to look back. Same with Tailwind.
100% this. It looks terrible until you try it and it starts making so much sense.
Also works great with agent assisted development.
I was very much in the Tailwind camp, and simultaneously loved it for its local reasoning and disliked it for how its long class names messed up my components. It has always felt like a bolted-on hack to me but I couldn't argue with the benefits.
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.
What is funny with your article is that you talk about tradition, when actually these traditions are based on assumptions which are themselves based on beliefs like : "separation of structure and style are a good thing".
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, ...).
I think this is a protypical discussion in tech. I have seen it soo many times in different areas.
The purists ("that’s how things ought to be!") and the pragmatists ("well but it works well and people understand it seemingly").
I don't recommend css. Css is BLOATED. And tailwind makes it a little less bloated, but it's still not strongly typed, and not very re-usable, especially in code.
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 ;)
Saying "unless you use @apply" invalidates this article for me. Everyone knows that @apply only exists as an escape hatch, it is not supposed to be used, except for when it's necessary like for compatibility with libraries that declare their own classes that you need to override.
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.
It makes no sense for me that @apply is frowned upon. It's what makes Tailwind actually kinda usable for me. Without it, markup looks like line noise full of boilerplate that's hard to modify in a systematic way.
I think what Tailwind actually needs is more abstractions, not to discourage the use of the sole abstraction @apply
Using @apply defeats the entire purpose of Tailwind. The point of it is to localize styling alongside the markup. If you're using @apply then you're constantly context switching from your markup to your CSS files while working.
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).
I use @apply in quite a few projects, mainly because I like the defaults in tailwindcss. I know it defeats the point of tailwind, but I find that it works nicely when using BEM.
I genuinely don't understand, why would you use `@apply text-center` instead of `text-align: center`?
Like if you're already at the point of setting up stylesheets & classes with a pre-processor why would you do that and not say use scss with some mixins for the more complex reused parts? At that point any IDE plugin that knows CSS can give you completion and your compiled sources will look a lot like the written ones in the dev tools.
Personally I wouldn't use `@apply text-center` over just `text-aligh: center;`, but I do use `@apply text-red-300` or `@apply px-2`, simply because I like the set of defaults Tailwind comes with.
I tried building my own set of defaults, but eventually decided that just using the Tailwind ones is much easier.
Show me one non-trivial project with classic, well-organized CSS usage and clean semantic HTML. It just never works out. There were attempts like BEM, which looks promising at first sight but is awkward at some points and only works if all devs strictly follow the convention. We all know how this usually works out. I once was that semantic HTML and css classes guy too, I completely changed my mind. In the end, we want to efficiently build a clean and shiny website. No real user looks into the (unminified) HTML source code to appreciate those awesome, sophisticated semantic CSS classes.
I tried to use Tailwind in a hobby project couple years ago. I havn't updated my CSS skills since 2010 or 2015 -- I certainly missed grid layout and some other new features.
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.
This is written from a point of view of somebody who never went through the progression of CSS to CSS preprocessors to component-based frontend libraries. Tailwind is an answer to all the problems that become apparent in CSS in that progression.
I also don't recommend TailwindCSS.
I instead recommend using HTML + CSS in a way that scales. Plus using a framework that supports scoped components helps.
I'm writing a web developer guide on using HTML + CSS and JS only when you need it: https://webdev.bryanhogan.com/
I'm also using the described approach in building a Astro starter template: https://starter.bryanhogan.com/
CSS Modules are a better solution. They compile classnames into unique identifiers, so there's no need for BEM or SMACSS conventions:
https://x.com/efortis/status/1888304658080256099
I disagree. I don't want to jump between two files constantly. With Tailwind I can stick to one file and never need to think about naming things.
Right so it is easier to write code quickly, but not to maintain a system. Tailwind is the right tool if you want to generate a prototype with LLM agents. It can be quickly deleted or can be used as visual prototype to create reusable components. And once the component is built for long term maintenance as priority, the collective knowledge has been built up so naming becomes simpler, important and elucidating.
The component itself is the semantics, adding naming over CSS classes adds no value whatsoever, only adds cognitive load and requirement of context switching to understand "what does this named class actually do?"
Strongly disagree with the point of not learning CSS. Bootstrap and the sorts that were en vogue before were terrible abstractions.
All the mental models required to be good at writing proper stylesheets are trained nicely with Tailwind
You have to know CSS to work with tailwind, it literally demands knowledge of the underlying rules.
What's so strange with Tailwind users is how insistent they are to impose it to codebases they don't know. I've never seen this even with vue vs react.
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.
Your complaint is about bad developers, not about Tailwind. Using Tailwind correctly means making heavy use of components to avoid duplication. Using Tailwind also removes the burden of having to do one of the hardest things in software: naming things, which is what semantic classes requires you to do.
I'm not a frontend guy so take this with a pinch of salt, but for a few personal projects I've done my approach is now "ai pls generate css". I thought it would be inconsistent and broken, but if you tell it to care about accessibility and you're willing to clean up a bit it's not that bad and you end up with very compact transfers after minification.
I tend to like simpler/textual interfaces though, admittedly this won't be everyone's cup of tea.
I've used a lot of tailwind professionally over the last few years and I agree with this article - it is spot on.
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).
I have the opposite experience regarding where it’s useful. In large teams , using an atomic css framework provides good guard rails and predictable behavior. I can confidently copy a marketing page or some random thing on the other side of the company and with very minimal tweaking, it will probably work. With normal CSS, the cascade is much more likely to cause subtle shifts in behavior over time as the main stylesheet is extended and modified.
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.
Tailwind requires a certain mental shift. That typically comes on a project where you feel like "there needs to be a better way", then you read https://tailwindcss.com/docs/styling-with-utility-classes and feel like BINGO!
Using @apply totally KILLS Tailwind - that's the clearest tell that the author didn't have that moment yet. Hence the other arguments in the article that feel somewhat petty.
God help me, somewhere around 2016 I started using some alpha version of Bootstrap 4, and I just keep using that same version for all the basic stuff underneath my own SCSS for whatever I'm building. It's absolutely fine. A lot of it is displaced now by grids, but for flexbox stuff and modals and pushing rows and columns it just works. Very easy to remember class names and extend it. Thankfully I don't work for a company that cares about using the latest thing.
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.
I'd appreciate a way to disable the real-time chat on this website, I don't see a way on mobile. It's currently full of racial slurs.
> there is a ceiling of basic classes you have to internalize
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.
Ergonomics for hand composition are less relevant now. The most important trait is how does a long-lived project perform when written by a coding agent.
I’m curious if anyone has any takes on the different approaches to agentic styling.
I’ve tried Tailwind for this without further steering, and after a while the agent starts adding unnecessary utility classes everywhere. Then I taught it to micro-Ralph eval all its utility classes using screenshots and this works ok but burns a lot of tokens. Treats the symptom and not the problem IMO.
Maybe with the right set of constraints there’s a subset of Tailwind that composes better? I went back to vanilla CSS for now, on the hope that it will readily port to whatever the best thing ends up being later.
My (certainly not unique) take is: As with almost everything, choose what you use based on context. There is a very wide range of websites and web applications you can make. For some of those tailwind is a good fit. For many it is not.
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.
> It breaks the separation between structure and design
I have a problem with this argument because CSS _itself_ breaks that separation.
`border: 1px solid red;` is design, but `display: flex;` is structure.
In my opinion, it makes sense for display properties to live in the HTML because they are by their very nature very tighly coupled to the markup.
Though I appreciate that making this distinction creates a separate problem of your team having to exercise good judgement (and consistency) in which CSS belongs where.
Tailwind didn't happen by chance - it was the culmination of many other failed philosophies for addressing a problem with CSS when it gets large.
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.
After trying a Tailwind-adjacent library myself (UnoCSS) I came to the conclusion that it's awful, but it's the least awful among worse alternatives. Having gone through BEM, I have no desire to go back there. Layers, modules, and scoped CSS seem like they could address a lot of the pain points in semantic CSS that TW was trying to, but I've never used any of those in anger save for Vue's emulation of scoped CSS.
IDEs can autocomplete tailwind classes but eventually you just memorize them, also with AI assisted coding I don't even write the classes anymore just small adjustments like changing pt-3 to pt-4, AI implemented dark mode in a small app I am working on in one shot, I think tailwind being in the training data helped tremendously with the task.
Coming from Qml, reading css/html is mind numbingly hard.. Haven't seen any other come even remotely close to the readability of Qml. I am talking generic UI development, not just for browsers.
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.
I've seen one of these posts every 6 months for the last 5 years and not a single one has figured out components yet.
What exactly is there to figure out or what would you like them to figure out?
Using them perhaps? Complaining about separation of concerns never makes any sense when you use components because the components are the structure and the styles are tightly coupled. You could separate the styles, almost all of them are going to be specific to the component so there's not much of a point unless you really like writing one-off class names.
In my opinion, the main problem with Tailwind is that it attempts to replace all CSS. Tailwind classes are often non-semantic and don't align well with CSS property names. Where pure CSS can be used, the code will be cleaner and more readable. It's important to remember that HTML has a "style" attribute, and it's often much easier to define a style block directly in the "style" attribute than to use a fragment and Tailwind's cumbersome CSS classes.
This discussion again. We've been having it for 6 years now and Tailwind remains popular. Lindy's Law tells us it will remain popular for a while longer.
Many people are productive in it, others hate it. Carry on.
> It is hard to read
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.
The argument basically boils down that in non-component approach (so not a modern web framework) it is harder to reason if you use tailwind classes. The rest is some serious bikeshedding, imo.
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.
Tailwind is great. Not sure why you'd use anything else at this point.
My personal experience (for what it's worth): I've used Tailwind across various project of different sizes for about one year then simply stopped using it. I just don't see any real advantage to use it over regular CSS.
The problem isn’t tailwind, it’s 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.
Counterpoint: the problem is actually HTML and most of webtech is increasingly elaborate cope mechanisms to deal with the original sin.
Every technology is going to have a problem, if you install something new, you'll have to discover the problems, if you use the standard tech stack, you will know exactly what the problems are.
I wish it would at least be kept out of UI frameworks.
Honestly, I found managing a Bulma codebase significantly more of a pain in the ass than Tailwind. Tailwind offers the expressiveness of actual CSS with the ability to make quick changes on the fly. As someone who has spent a lot of time working in CSS frameworks over the years, it is one of the better abstractions of its kind.
I sort of feel like this argument is trying to put a train that is already halfway across the country back in the station on the East Coast.
I switched from Tailwind to plain CSS with a UI library and it honestly made my site look better. Probably because it's much harder to spam backdrop effects.
I agree with all points and they are the reason I'm very selective which project uses it and which doesn't.
It did give me some ideas for my own stylesheet writing though. The colorsystem is something even non-tailwind projects will have now.
Pre-llm era Tailwind was great for the backend people who did not want to learn CSS. Nowadays agents got this. Openprops might be a good option even with agents, at least for me it works well. Not a surprise that Tailwind popularity dropped significantly.
I think the another llm-victim is React. For a while it was great to have a heavy framework that somewhat standardised webdev's JS approach. Astro just become the default goto lightweight option that is great to quickly build a nice simple UI.
I’d be rather interested in a recommandation that don’t comes with de usuals pits of others solutions and comes with a the actual css code that will apply to the element displayed in autocomplete while editing the html / jsx.
I think having an unmoderated chat directly on the page certainly is a choice…
Not a big fan of vanilla tailwindcss too, but (from the perspective of someone that needs the job done) "just use modern CSS" as the author suggest is even worse.
Honestly I tire of this debate. Both sides have good points have both choices are valid.
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.
That’s exactly how I’m doing this using tailwind and daisyui though, so I’m not sure what point you are trying to make?
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.
if you don't like this.
why not write it like this?Or:
Fair comparison (i really don't like this too): ;-)"Nothing stops you from using sky-400 and blue-400 in the same project. Consistency still depends on your discipline, not on the framework."
And how did plain css solve that? You're mixing up a few issues there.
My counter-argument: I can copy any cool-looking Tailwind element I find on the Internet into my own project and it'll look exactly the same.
I think tailwind helps. It is same as AI prompting, but in a deterministic and fine-grained way. Bottom line - it reduces the time to build.
We already tried the fully semantic web in the days of XHTML, where the document is purely semantics and CSS purely transformation.
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.
I am building a version 2 of my FCSS framework. https://github.com/meerita/FCSS2 check it out, fork it, use it, you're welcome.
The cat shoutbox thing was fun, but it stopped working.
I'm still on bootstrap, and it still works for me.
> The problem with Tailwind is that you cannot resolve this ambiguity even by reordering your classes.
I guess the author has never heard of tailwind merge.
It’s funny how, upon opening the website, you’re immediately greeted with a “Was Top 1 on Hacker News” link leading back here, but (at time of writing) it has under 50 points and almost every comment disagrees with the post.
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).
People tend to overlook the main benefit of Tailwind: components and pages become self-contained. As such, changing them doesn't cause unintended side-effects to other pages and all or parts of a component can be dropped into another page and it "just works." This is a huge benefit as the normative/intended behavior of CSS makes changes risky on large sites. Now, there are other ways to do this, but Tailwind is quite effective at it.
> .red-color{
> color:red
> }
> .big-text{ font-size:20px }
My theory is that higher-level abstractions don't need to add any value to be popular, you can just create a single dependency that abstracts away one lower level dep, and people will use it only because they want to avoid learning something, in the end they will actually learn the thing with a proxy in the middle, but at least they took a shot at skipping the 'grind' of learning css.
I know complaining about the site is poor form, but it is really hard to take advice seriously for a site that lets other visitors spam... just general internet things to other visitors.
Cute idea, but it is pretty clear the author doesn't consider practical consequences, so why should I trust their judgement about Tailwind?
I can immediately spot organizations void of any skilled frontend engineering leadership by their use of 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.
Straight from my heart - i couldn't have said it better. I always had this answer in my head, but nobody asked and it felt senseless to talk about unpopular opinions. Now you have been faster than me, here under the umbrella of the tailwind-topic - but you should know, you are not alone with exactly that attitude.
tailwind is the worst thing ever, i hate this so much
ok
My sass customers don't even know what css means, it's fine. Nobody cares as long as the things they expect are on the page in the right position and font is readable.
Do your sass customers know what javascript is or how it's different from java? Does this mean developers shouldn't care either?
They don’t, unfortunately. Any time I bring up the wonders of Elixir/Erlang or how great Postgres is, their eyes glaze over unless they have some kind of technical background. I’ve had many conversations where people were surprised there’s more than one programming language, they assume it’s some sort of 1s and 0s that flash past the screen Hollywood style.
I registered my first domain 1997 and before that already coded websites: members.aol.com/…/
I saw the inception of CSS, the infamous ACID test, IE6, web standards movement - anything and everything.
To this day, CSS is something that is not separating design from markup (try logic, you will get it), and as all things technology is now a mix of technical constraints, backwards compatibility, totally conflicting decisions.
I am traumatized with floats and clearfix, and there was a lot of debate around CSS 3, JavaScript.
Layout wise, “the web” aka web traditionalists or whatever went bezerk against any attempts to allow for what today is dominating: print layout as role model.
Formerly flow was all about responsive web design, being as fluid as it gets.
CanIUse had to be brought to life to solve the questions, what features needed to be done in JavaScripts, which not.
Stylus, BEM, bootstrap, SCSS etc.
All kind of conventions and preprocessing helpers.
CSS is hard and will stay hard, in fact I am stunned by the author’s total ignorance of where CSS came from, why something is the way it is.
Maybe he is just a young gun and thinks that CSS is only flow, grid and CSS3 and always waiting for cool new features which do what? What purpose do they have, which problem do they solve?
Tailwind is genius. There is pro and con for everything but looking back it is just another evolutionary step on the shoulder of the mentioned giants.
To this day no framework or system was more simple and elegant than Tailwind.
The author’s naive conclusion is a variation of the running gag that started with https://youmightnotneedjquery.com/
Tailwind is shadowing native CSS functionality? I felt pain reading this because so what? That”s not the point.
We use preprocessors, postprocessors, optimizers - what I don’t want to do is using CSS’s own bad naming nomenclature which is used because of backwards compatibility.
In fact abstracting away basic functionality and simply let the compiler decide what is best given the situation is mentally helpful.
Working in large teams, or many teams. Guess what will happen: we build our own CSS framework, well we build ten because everyone knows best.
The author really should be thankful for the genius job Tailwind does, because he seems extremely inexperienced and never faced hard challenges.
In fact if your only problem is to decide between two frameworks, you are lazy and not considering other people.
Browser compatibility, breaking changes, different CSS as well as JavaScript engines - this was brutal.
Today? Luxury discussions.
The fact that Tailwind allowed for a gazillion of partly stunning CSS design systems and React components like ShadCN and others is proof enough that Tailwind is a platform with the best pro/con ratio so far.
This has never been the case before. This is a singularity.
I was founder and product lead for a huge and critical to business financial platform, seeing others easily augmenting your platform via interfaces or plugin patterns as a structured approach is genius.
Extensibility is a sign of elegance and perfect abstraction.
Are there downsides? Who cares with all these never seen before massive benefits?
The killer against laissez fair CSS is exactly this: have you ever lead an approach to develop a framework? Why do you want to build yet another TW?
Drop it. It won’t work. The question or better your solution hints at being a solo dev.
This is fine but you seem so one sided in your views, I am puzzled.
If I could use just native CSS boy oh boy - do you really know everything about it? Could you understand a floating layout? Could you see pro and contra for its use case or do you just not allow its usage? If yes, why if you cannot answer the question?
How do you make sure, there is standardization? How do you train and coach people so that they know and can use CSS?
What are your naming conventions? Why this way, no other way?
How do you deal with devs leaving, new joiners?
Who is overseeing the repository? Who has merge rights? Who does the code reviews?
What do you do if there was an emergency and some big shot or very important order had to be accommodated and now you have garbage CSS in your platform that you must maintain and everyone can use?
Boy oh boy - I love Tailwind. The versatile solution that was 30 years in the making.
All you delusional freaks out there with the hubris belief: tell me how it went.
I just covered a few questions. Deployment is yet to debate etc.
Nobody does. Yet it is everywhere, like AI slop.