--- title: Why I don't recommend Tailwind CSS | daily.dev description: A critical look at Tailwind CSS covering eight specific drawbacks: the steep class-learning curve, breaking HTML/CSS separation, inconsistent naming... canonical: https://daily.dev/posts/why-i-don-t-recommend-tailwind-css-kqnuxrv44 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Why I don't recommend Tailwind CSS | daily.dev og:description: A critical look at Tailwind CSS covering eight specific drawbacks: the steep class-learning curve, breaking HTML/CSS separation, inconsistent naming... og:url: https://daily.dev/posts/why-i-don-t-recommend-tailwind-css-kqnuxrv44 og:image: https://api.daily.dev/og/posts/kqNUxrv44.png og:image:alt: Why I don't recommend Tailwind CSS og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why I don't recommend Tailwind CSS **[Hacker News](https://daily.dev/sources/hn)** · 10 min read · 242 upvotes · 73 comments ## Summary A critical look at Tailwind CSS covering eight specific drawbacks: the steep class-learning curve, breaking HTML/CSS separation, inconsistent naming conventions, the false sense of design-system enforcement via arbitrary values, being a poor learning path for CSS fundamentals, readability problems, misleading cascade priority in HTML, and uncomfortable DevTools debugging. The author contrasts Tailwind with modern vanilla CSS features (cascade layers, native nesting, custom properties, container queries, :has()) and concludes that while Tailwind has valid use cases in large component-based projects, it carries hidden long-term costs and competes with a much more capable native CSS platform than existed when it was created. The recommendation is to learn CSS first, then decide with full context. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 188 comments across hackernews (as of 2026-08-02). **TL;DR:** The community is broadly split but leans toward pragmatic acceptance of Tailwind: many experienced developers defend it as a practical solution to real CSS-at-scale problems, while critics argue its cascade behavior, class verbosity, and escape-hatch dependencies are genuine design flaws rather than bikeshedding. **Sentiment:** 45% positive · 35% mixed · 20% skeptical **The case for** - Tailwind enforces a component-based styling paradigm that prevents the organic deterioration of CSS codebases over time. - Utility classes keep styling co-located with markup, eliminating constant context-switching between HTML and CSS files. - Copying Tailwind-styled elements from external sources into a project produces consistent results without cascade interference. - Onboarding new developers is faster because conventions are standardized and discoverable rather than organically grown. - Works well with AI/agent-assisted development due to its predictable, explicit class names. **The pushback** - The cascade resolution of conflicting utility classes (e.g. text-red-500 vs text-green-500) is determined by stylesheet source order, not markup order, quietly breaking the 'locality of behavior' promise and necessitating runtime dependencies like tailwind-merge. - Long chains of utility classes in markup reduce readability and make systematic style changes harder than with named CSS classes or modules. - Tailwind can encourage design drift and inconsistency across large teams if components aren't rigorously extracted. - Using @apply as an escape hatch undermines Tailwind's core value proposition and reintroduces the context-switching it was meant to eliminate. - Developers who rely solely on Tailwind may avoid learning modern CSS features (variables, @scope, cascade layers) that solve many of the same problems more elegantly. **By community** - hackernews (mixed): Commenters are deeply divided, with pragmatists defending Tailwind's real-world productivity gains and purists raising legitimate concerns about cascade behavior, escape-hatch overuse, and the loss of semantic CSS discipline. **Hottest debate:** Whether the need for tailwind-merge to resolve conflicting utility class precedence is a fundamental design flaw or an easily avoided non-issue. **Open questions** - Does Tailwind's enforced component-based paradigm actually prevent design drift in large multi-team codebases, or does it just shift the sloppiness? - At what project scale or team size does the tradeoff between Tailwind's DX benefits and its cascade limitations tip one way or the other? - Will modern CSS features (@scope, native cascade layers, CSS mixins proposal) eventually eliminate the problems Tailwind was created to solve? **Highlights** > 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. > — [guessmyname on hackernews · 2 comments](https://news.ycombinator.com/item?id=49142403) > 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. > — [DanielHB on hackernews](https://news.ycombinator.com/item?id=49143321) > 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. > — [9dev on hackernews · 2 comments](https://news.ycombinator.com/item?id=49142954) > 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: const classList = tailwindMerge( 'p-4', size == 'sm' && 'p-2', size == 'lg' && 'p-6', ); 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. > — [9dev on hackernews · 1 comments](https://news.ycombinator.com/item?id=49142735) > 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:
  • Title
    Subtitle
    • 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... > — [SebastianKra on hackernews · 1 comments](https://news.ycombinator.com/item?id=49143261) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49141891) · 69 points · 188 comments ## Community discussion Top comments from developers on daily.dev. **@orcdev** · 56 upvotes > ![GIF](https://static.klipy.com/ii/e293a233a303a98e471f78d04e13a1b0/bb/bf/Ri0oayQw.gif) **@toxictoast** · 31 upvotes > Tell me you haven't shipped a large-scale React component library with a team without telling me. > > This reads like a 2012 critique applied to modern component architecture. > > The core mistake is confusing "Separation of Technologies" with "Separation of Concerns." > > In modern UI engineering, components encapsulate structure, logic, and style. Tailwind doesn't ruin your HTML - it keeps component styling colocated, predictable, and scoped. > > Vanilla CSS has made great strides, but native CSS still doesn't solve naming fatigue, specificity wars, or dead-code accumulation in large teams. > > Tailwind... **@heracles2756** · 25 upvotes > I find Tailwind CSS harder to maintain as a project grows. > > I think Sass is more practical because its nested structure makes styles easier to organize, read, and maintain. **@confidentcoding** · 8 upvotes > _"The recommendation is to learn CSS first, then decide with full context."_ > > Well, yeah...but that is not the sensible approach the article title indicates. 🙄 **@ksolomon** · 8 upvotes > _breaking HTML/CSS separation_ > > How, exactly? Last time I looked, if you're using vanilla CSS/SCSS/SASS/whatever, you're still putting classes in your HTML. > > I use Tailwind, and while I don't necessarily like it or agree with some of the decisions made, I can't deny it makes things easier. And let's face the real facts here...these days, most folks aren't even writing it by hand. They're doing something along the lines of "here's a screenshot, build this for me" in an agent, then watching YouTube for an hour. > > But that's a different conversation... ## Similar posts on daily.dev - [Vendor locked](https://daily.dev/posts/vendor-locked-cjtpyyhik) · stitcher.io · 30 upvotes · 9 comments --- Tags: [#webdev](https://daily.dev/tags/webdev), [#css](https://daily.dev/tags/css), [#tailwind-css](https://daily.dev/tags/tailwind-css) [View this post on daily.dev](https://daily.dev/posts/why-i-don-t-recommend-tailwind-css-kqnuxrv44) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Why I don't recommend Tailwind CSS","url":"https://daily.dev/posts/why-i-don-t-recommend-tailwind-css-kqnuxrv44","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/why-i-don-t-recommend-tailwind-css-kqnuxrv44"},"datePublished":"2026-08-02T08:58:19.794Z","dateModified":"2026-08-02T20:17:32.219Z","description":"A critical look at Tailwind CSS covering eight specific drawbacks: the steep class-learning curve, breaking HTML/CSS separation, inconsistent naming...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/06d1cc19a781d48114465427142d9c13?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/06d1cc19a781d48114465427142d9c13?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":73,"discussionUrl":"https://daily.dev/posts/why-i-don-t-recommend-tailwind-css-kqnuxrv44","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":242},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":73}],"keywords":"webdev,css,tailwind-css","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Why I don't recommend Tailwind CSS"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/why-i-don-t-recommend-tailwind-css-kqnuxrv44","comment":[{"@type":"Comment","text":"","datePublished":"2026-08-02T10:42:02.798Z","url":"https://daily.dev/posts/kqNUxrv44#c-VpiIQM0uD","author":{"@type":"Person","name":"OrcDev","url":"https://daily.dev/orcdev","image":"https://avatars.githubusercontent.com/u/7549148?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":56}},{"@type":"Comment","text":"Tell me you haven’t shipped a large-scale React component library with a team without telling me.\nThis reads like a 2012 critique applied to modern component architecture.\nThe core mistake is confusing “Separation of Technologies” with “Separation of Concerns.”\nIn modern UI engineering, components encapsulate structure, logic, and style. Tailwind doesn’t ruin your HTML - it keeps component styling colocated, predictable, and scoped.\nVanilla CSS has made great strides, but native CSS still doesn’t solve naming fatigue, specificity wars, or dead-code accumulation in large teams.\nTailwind isn’t a substitute for CSS fundamentals; it’s a design system engine that eliminates friction at scale.\nHope this helps to Debunk this Bullshit Post.","datePublished":"2026-08-02T13:55:08.122Z","url":"https://daily.dev/posts/kqNUxrv44#c-uv60tNfDe","author":{"@type":"Person","name":"ToxicToast","url":"https://daily.dev/toxictoast","image":"https://avatars3.githubusercontent.com/u/13606388?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":31}},{"@type":"Comment","text":"I find Tailwind CSS harder to maintain as a project grows.\nI think Sass is more practical because its nested structure makes styles easier to organize, read, and maintain.","datePublished":"2026-08-02T11:18:04.530Z","url":"https://daily.dev/posts/kqNUxrv44#c-47xbsxGfb","author":{"@type":"Person","name":"heracles 2756","url":"https://daily.dev/heracles2756","image":"https://media.daily.dev/image/upload/s--NoOPHSFv--/f_auto/v1785506917/avatars/avatar_iYIZwiJAMuCGXY2OiXW0x?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":25}},{"@type":"Comment","text":"“The recommendation is to learn CSS first, then decide with full context.”\nWell, yeah…but that is not the sensible approach the article title indicates. 🙄","datePublished":"2026-08-02T13:18:46.174Z","url":"https://daily.dev/posts/kqNUxrv44#c-hfgiWlz2I","author":{"@type":"Person","name":"Lars Faye | Confident Coding","url":"https://daily.dev/confidentcoding","image":"https://media.daily.dev/image/upload/s--OGZu5DEc--/f_auto/v1772569630/avatars/avatar_umWZ9aQAng34qk5aaJl2q?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":8}},{"@type":"Comment","text":"breaking HTML/CSS separation\nHow, exactly? Last time I looked, if you’re using vanilla CSS/SCSS/SASS/whatever, you’re still putting classes in your HTML.\nI use Tailwind, and while I don’t necessarily like it or agree with some of the decisions made, I can’t deny it makes things easier. And let’s face the real facts here…these days, most folks aren’t even writing it by hand. They’re doing something along the lines of “here’s a screenshot, build this for me” in an agent, then watching YouTube for an hour.\nBut that’s a different conversation…","datePublished":"2026-08-02T18:23:09.302Z","url":"https://daily.dev/posts/kqNUxrv44#c-oB8ahWtVp","author":{"@type":"Person","name":"Keith Solomon","url":"https://daily.dev/ksolomon","image":"https://avatars.githubusercontent.com/u/251996?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":8}}]} ```