I Love Tailwind. Sorry Not Sorry

Haha just mark me in the article 😀

Adam - The Developer • May 6

man of culture here, of course I do.
but I'll do YOU one better...

WHY I Love Tailwind. Sorry Not Sorry.

Richard Djarbeng • May 7

Is this from WHY is Gamora? From Avengers. If so I understood that reference

Hahahahaha I’m crying 😂

Do it! And then I’ll follow up with: “What is Google Search? Sorry not sorry” 😄

Giorgi Kobaidze • May 4

I’m gonna write another article: “I don’t care about Tailwind, sorry not sorry” 😂

Ben Halpern • May 4

lol

I love this comment 😂 You absolutely have to write that article, it would be a banger 😄 On the other hand, maybe you should care! Every time I had to build a frontend with backend devs, they always asked for Tailwind because they didn't understand plain CSS 😂

Giorgi Kobaidze • May 4

I used to write a lot of css back in the old days, so I’m pretty familiar with both. Strange right, coming from a back-end dev😄

In that case, you’re a unicorn 😄 Most backend devs I’ve worked with either break something in CSS or just avoid touching it altogether. 😅

Giorgi Kobaidze • May 4

To be honest, I don’t feel overwhelmingly excited when writing CSS. But sometimes I just gotta do it, cause I’m a one-man team😄

Ben Sinclair • May 4

In real projects, that long Tailwind class list usually lives inside a component anyway. You don’t copy-paste that everywhere

That's why components aren't reusable under tailwind.

Tailwind doesn’t create bad developers.

It kind of does, in all but name. People use Tailwind because it's popular. LLMs train on it because it's popular. The people who use it most don't care about semantics. They don't care about accessibility. They don't care about users. It goes around in a circle. If you ask an LLM for something, it loves using Tailwind because it has no idea about the rest of your code and is happy to produce slop.

Of course you can build reusable and configurable components with Tailwind — and it doesn’t require any kind of wizardry 🙂

And yes, LLMs love Tailwind, but it was already hugely popular long before that. There was even that whole discussion about Tailwind creators losing traffic because people stopped going to the docs. Also, if you ask an agent to write plain CSS without supervision, it will happily generate unusable slop as well.

The part about accessibility and semantics feels like a generalization. You can build semantic, accessible UIs with Tailwind — and you can also create a complete mess with plain CSS.

Ben Sinclair • May 5

I don't think people generally build reusable components with Tailwind. Or rather, there's a spectrum of Tailwind that goes from inline styles at one end to regular CSS at the other end, and the more reusable a component is, the further from Tailwind's goals it is. Don't forget Tailwind was explicitly written to counter the separation of style and content and the documentation advices you to steer clear of anything else.

A component isn't reusable if it has hard-coded styles - and if you try to separate them out by collecting utility classes into something more semantic then you're going down the CSS end rather than the Tailwind end. If you use Tailwind variables in JS for values then you're reinventing the wheel again, meaning there are now more places to configure things, and that you need to edit code to change the look and feel.

You can build semantic, accessible UIs with Tailwind, people just don't tend to, the same way React components don't tend to be built that way. Almost all the tutorials for either are div soup, and that's what people learn from. Tailwind's massive popularity has had the incidental effect of making the web worse.

And the more you try to make Tailwind into something usable, the closer you get to what you'd have had if you'd used regular CSS in the first place.

There’s a lot of emotion and generalization in this take, and a strong sense of “how things should be.”

I do agree with some parts though. If you’re building highly configurable components, classic CSS can be more convenient. And yes, the more abstraction you introduce, the closer you get to a more traditional CSS approach, which can be the better choice in that context. The point about tutorials is also fair, but that’s not a Tailwind issue, that’s a tutorial issue. React tutorials look exactly the same in that regard 😄

Where I disagree is on reusability. You absolutely can build reusable components with Tailwind. You define components, pass props, and map classes. The whole modern UI approach still applies, including variants and composition. The same goes for the “hardcoded styles” argument, that’s just not how most real-world Tailwind codebases are structured.

Utility classes also aren’t the same as inline styles. You still have CSS underneath, including the cascade, media queries, and everything else that comes with it. And the argument about semantics and accessibility… the web has had issues there long before Tailwind came along. My own application built with Tailwind meets WCAG AA standards, otherwise it wouldn’t have passed the audit and wouldn’t be allowed in production.

And sure, beautifully crafted CSS systems can be great, even better in some cases. If a team has the time and conditions to build that, go for it. But in reality, you often have multiple teams, tight deadlines, and constantly evolving requirements. That’s when things tend to turn into unmaintainable spaghetti, because someone added a random custom class somewhere and nobody knows what it does anymore 🙂

How cool is that 😁

Andy Robinson • May 5

To be honest - Im just happy i got any engagement in my post!

Hahaha exactly 😄 At this point you don’t even need to write any more hot takes, the pure CSS defenders are doing it for you in the comments. 🤣

Pascal CESCATO • May 5

You’re absolutely right: Tailwind—or any tool, really—doesn’t create bad developers.

If anything, a mediocre developer may ship something cleaner-looking with better tooling, which just makes them slightly harder to spot. But better tools don’t magically turn mediocre developers into great ones.

This debate has existed forever. First it was “if you don’t write machine code, you’re not a real developer,” then assembly, then C, then Java, then “real devs don’t use frameworks”… and the cycle repeats with every language and stack: PHP, JavaScript, Python, React, Tailwind, you name it.

At the end of the day, what matters is solid fundamentals and choosing the right tool for the right job—taking into account real-world constraints like time, budget, maintainability, and team expertise.

And besides: my tailor is rich… because he doesn’t do bespoke unless you pay for it 😉

Thanks, Pascal 😄 Exactly — there’s always someone who’s a “more real” developer than the rest of us 😂

And the tailor analogy is perfect! I probably could’ve written a more balanced post like this… but then would we have had this much discussion? 😄

Pascal CESCATO • May 5

No, Sylwia, definitely not! Don’t change the way you write—keep bringing us your authenticity. That’s what gives your articles their flavor, and what makes them so engaging! (Well, let’s just say it definitely plays a part 😉)

dev.to/pengeszikra/javascript-grea...

No worries there — I usually write first, publish, and only then start thinking about it 😄

Peter Vivo • May 4

I like Tailwind also. My first impression that is create a messy HTML, and make a repetative solution. But after I start to use, I start separated the CSS to two main role:

layout
style I start put Tailwind to layout role, because Tailwind really shine in that scope. I hope this small codepart can really show how can I handle my mobil first game responsivity. ( I use my own JS FW instead React but use JSX well. )

/** @type {(props: { front:string, back:string, zoom?:number, children?:any }) => HTMLElement} */
export const GalaxyRoute = ({front, back, children, zoom=150}) => (
    <main
      class="
        relative
        bg-zinc-900 w-[100vw]
        overflow-hidden
        grid place-items-center
      "
      style={{
        backgroundImage:`url(${front}),url(${back})`,
        backgroundSize: `${zoom}vw`
      }}
    >
      <section class="
        relative
        --bg-rose-700/40

        max-w-[100vw]
        max-h-[56.25vw]

        portrait:w-[100vw]
        portrait:h-[56.25vw]

        landscape:mx-auto
        landscape:w-[178vh]
        landscape:h-[100vh]

        overflow-hidden
        grid place-items-center
        --pointer-events-auto
      ">

        {children}
      </section>
    </main>
  );

my game is also a good example where the original CSS beat the Tailwind ( 2025 ) the 3D game engine is pure CSS solution.

github.com/Pengeszikra/flogon-gala...

This is actually a very sensible approach. it nicely bridges my perspective with the original author’s take.

Using Tailwind for layout and responsiveness makes a lot of sense, because that’s exactly where it shines and speeds things up. But when things get more advanced, custom, or just a bit “weird,” I completely agree: pure CSS gives you the level of control you just can’t replace.

So yeah, I’m 100% with you on that split 🙂

Milton Rodrigues • May 4

What theme are you using in the IDE?

Peter Vivo • May 4

IDE? On the video I show the in game markdown editor with minimal code block syntax highlight.

A relevant CSS part:

sw { color: #fb8600}
rw { color: #acd641}
bw { color: #ac84d7}
ew { color: #ac84d7}
uw { color: #8f665f}
st { color: #2fd57f}
rm { color: #768d76}
jd { color: #9ea77d}
wt { color: #618be3}

Syed Ahmer Shah • May 6

Great breakdown of speed versus purity. In a production environment, predictability usually wins.

100% true!

FrancisTRᴅᴇᴠ (っ◔◡◔)っ • May 5 • Edited

I don’t think Tailwind (or something similar) should replace handcrafted CSS everywhere.

I don't think it was suppose to be replaced at all. It's just a library like Bootstrap. It's weird for me to think that a "library" will replace a core functionality. Sure, there are cases where that may replace something (which I can't think of anything at the moment), but that's usually rare for a library or framework since it mostly based on preferences of the Developer (Unless you are talking about AI lol). Although it makes it easier for developers, there are some cases where you have to use CSS like you listed for specific cases that Tailwind cannot do.

Yes, it's probably possible to replace CSS with Tailwind if you are a developer who wants to go full Tailwind or Bootstrap mode. For me, I like a good mix of both. Again, it's based on preferences and I don't think it's a big deal in my opinion. Thanks!

Yes, exactly 🙂 As long as it doesn’t turn into a mess where Tailwind is used in one place, plain CSS somewhere else, and no one really knows what goes where. You just need clear rules for when to use what.

And yeah, using Tailwind definitely doesn’t mean giving up CSS 😄

Dawn • May 5

I agree with oft-repeated concern about needing to keep styling close to the rest of the component code. My current structure uses a lot of magical global stylesheets, and I hate it because it's so hard to find where any particular style is coming from, and all that reuse makes it really brittle.

Single file components (I use Vue) resolve that problem 👍 The CSS, HTML and JavaScript all get their own sections in the same file for any one component.

Tailwind is pretty attractive if I only want one or two classes, but a lot of the time it just feels like we've saved ourselves a fairly small number of characters while effectively still using style="attribute1: value1; attribute2: value2; ... attributeN: valueN;".

I want that clutter out of my HTML.

I find scanning a vertical list of attributes much easier than a horizontal one.

I like how CSS lets me write blocks to clearly group styles at different breakpoints.

For me, CSS is cleaner and easier to read than Tailwind, as long as it's scoped (to prevent bleeding into other components) and stored alongside the HMTL it's being applied to.

That’s a really insightful comment, thanks for sharing 🙂

I’m curious though. Do you still see people actually building components like this by hand in commercial projects? I mean outside of hobby work. From my experience, in most real-world projects you end up using some kind of ready-made solution anyway, the question is just which one.

Dawn • May 5

Yup! Across nearly 30 projects in five years, built by different people, this has been the norm in my world.

This approach has generally been coupled with imported component libraries, which do tend to use Tailwind. Alas, the projects have often had a nasty mix of Tailwind, stylesheets and localised CSS.

You know my views on Tailwind 😉

Stylesheets have their place, but in my opinion just for small projects. They can quickly get out of hand, and then the magic of cascading just becomes chaos.

As for component libraries... I think they deserve a seperate response 😃

Out of curiosity… 30 projects in 5 years? I’ve been on the same one for 3 years now 😂 Is that an agency setup?

Dawn • May 5

Yup! Admittedly, one of those was just a three-day assessment of the scale of the challenge before the prospective client went elsewhere, but most were at least half a year and several were multi-year engagements. It was a mix of full time build phases (new projects, or big expansions to existing products), and maintenance contracts for a few days each month per client.

At my peak I think I had eight active clients at the same time. I promise I do not miss that level of context switching 😆

Dawn • May 5 • Edited

*On Component Libraries*

I have used several over the years, and intend to investigate more in the coming months. My key criteria are: providing the components I need but deem too fiddly to make in-house; those components being accessible; those components being reasonably easy to restyle.

Vuetify is what I am most familiar with, as that's what was used for most of the projects I was assigned to maintain. It's ok, reasonably easy to restyle most but not all things. My main gripe is how long it took them to build some of their components for v3 to be compatible with Vue3. It made them a non-option for a long time for anyone who needed those components, e.g. calendar.

Inkline is not something I would touch willingly, although it has its fans. For me, it was outrageously hard to restyle and far too many components were simply not accessible.

PrimeVue was impressive and very, very flexible. However, the number of ways to customise styles felt absurdly high, and I often ended up resorting to trial and error to find out which method would actually work for any given combination of component and desired restyling. Not smooth, just frustrating.

For a project without complex styling ambitions or a strong visual brand to achieve, I think component libraries are a great way to make a website look decent and modern without too much hassle. They free us to focus on functionality 🙌

For simple components like buttons, though, I think they are overkill if your project has its own bespoke design, as it can be easier to just create your own components around vanilla HTML elements rather than restyle something else.

For complex components, like anything date-related, it could be a fun exercise for a hobby project but I wouldn't dare bill my clients for that amount of effort when off-the-shelf offerings have already tackled all that pain. Give me imports!!!

Where external component libraries are used, I would strongly recommend accessing them via custom components. Wrap the imported component in your own styling, once and only once, then use that. In my experience, it is significatly better than ended up with a mix of high level style sheets and in-place CSS to override the componets' default styles where they do not match the look of your project.

david duymelinck • May 4

What I get from the post and the comments is that most people think writing CSS is starting from scratch every time. When that is your workflow I can understand why you want to use Tailwind.

You don't need to create a whole design system. Start with components that are very common like hero, input, button, navigation, ... After a while you will have a collection to build almost every website. To get started quickly you can use Tailwind, one of its purposes was quick prototyping. But the prototypes ended up in production as it goes with a lot of code.
The main benefit of working that way is that it is build to your (teams) taste. With Tailwind you have to accept their naming.

About the maintenance of the components. When do you really need to change them? When you want to benefit from new CSS features.

About the dead code. Tailwind used a build step to collect all the classes in html files to generate the production css file. It is not that hard to write a script that does the same for your code.

Using "crafty" CSS doesn't mean you can't create tools to make you as productive as with Tailwind.
And by keeping closer to CSS it is easier to change direction. Tailwind is an oil tanker because it is that popular.

This is a great comment, probably the most architectural take in this whole discussion 🙂

In theory, I really like this approach. In practice… I honestly don’t know when I’d use it. Across all the projects I’ve worked on, it was always either a ready-made component library (like Angular Material) or Tailwind (often with shadcn). For context, most of my experience comes from startups.

The closest I’ve seen to a custom component system was our Head of Design in my previous company. He almost convinced leadership that a beautiful, fully custom UI would improve sales… but once they saw the estimates, they told him to go find a ready-made library 😄

And in corporate environments? There wasn’t even a conversation about flexibility. That decision was already made long before any code was written.

david duymelinck • May 4

I get the hit the ground running aspect from the business side. But the consequence is that with shadcn you are two abstractions away from CSS.

I think the head of design made the mistake to estimate a big bang solution. I think it is better to show the vision and estimate the startup phase. And after that each feature uses X procent of the time to build towards the vision. That way the startup phase looks like the biggest effort.

True in some occasions it are not developers that are making the decisions. It is not always the most enjoyable feeling, but is work. You can find joy in private projects.

When it comes to that designer, honestly, whatever approach he chose back then probably wouldn’t matter today anyway.

It was one of those startups that completely fell in love with AI, and now the main criterion for choosing a stack is basically “what AI is good at.” So… most likely Tailwind 😄

Elmar Chavez • May 5

I've built multiple web apps with vanilla CSS. When I switched to Tailwind, I don't like it at first. I don't like having to read multiple class names in my HTML. It somewhat breaks my own personal code. I like HTML and CSS separate.

But over time it grew on me. At first I have to look up equivalent class names from the official Tailwind site. That was the only struggle. It replaced my old struggle of thinking about custom class names following a naming structure like BEM. Once I deployed enough projects, I realized that Tailwind is not as bad as it seems.

However, I totally agree that we should be able to ship projects with vanilla CSS first before using Tailwind. Not only because you will be missing the fundamentals, but also you will not be able to fully appreciate the pros this CSS library brings to the table.

Exactly, and the benefits of Tailwind become even more noticeable in larger teams 🙂

And yes, fundamentals are a must. If anything, they’re becoming even more important in the age of LLMs. I was actually wondering recently how people will learn programming if the “coding” part is increasingly handled by tools. But then a friend of mine, who’s getting into programming, just sat down and started learning C++ from scratch… and it reminded me that this isn’t some kind of secret knowledge after all 😄

Julien Avezou • May 4

I also am a Tailwind fan, have been using it for years in my projects. Speed and consistency are big positive factors. The tradeoff is that it does look the code look more verbose but it's an accetpable tradeoff imo for the productivity gains.
I also agree with your pragmatic approach of also adding CSS by hand when it makes sense. I often do this for more custom UI as you mention.

Exactly, lots of criticism, and then everyone ends up using it anyway because it’s fast and convenient 😄
And honestly, the verbose code doesn’t bother me either, you get used to it really quickly.

leob • May 4

Arguments well made - I think the author of the original article is an expert CSS craftsman, who really loves his craft - and as you say, it still does have a place ...

But for most of us, who are mediocre or maybe "reasonably good" at CSS, Tailwind just delivers benefits :-)

Haha, of course! I totally understand and respect that! There will always be a place for beautifully crafted CSS 🙂

And about skills vs Tailwind: someone can have an amazing skillset, but it only takes one backend dev jumping in to “just fix something,” and a month later nobody understands what’s going on anymore 😄

leob • May 4

Yeah good point - Tailwind is just (well, just, lol) about having a "standard way", structure and predictability, especially in a team setting ...

It's like building a house with prefab parts, or assembling IKEA furniture, etc - good enough for most use cases, but in some cases you still want the "craftsman" bricklayer or carpenter :-)

I love the IKEA comparison 😄 And honestly, I always get my kitchen furniture from IKEA. 20-year warranty, can’t argue with that!

leob • May 4

20 years? Wowww :-)

Andy Robinson • May 5

Its true, I do love writing CSS - even though most of the time I'm writing backend code.

Arik • May 7

In a world full of entitled “rant” posts it’s refreshing to see some love for a genuinely great product. People forget that open source might be free for them but anything but free for the people creating the software.

Exactly! It's so important to see also the good side. Thanks for this comment 😊

Kasope Johnson • May 5

Didn't want to comment, cause this "war" is getting tiresome. But maybe this will help someone:

I use tailwind a lot.. it's the backbone of my design system.. we use a highly themable component system with different variants/states (class-variance-authority)

I'm following the Atomic design style.. I have smaller components (buttons, badges etc) and then bigger components (combo boxes, file uploaders) etc

That's all that matters, with atomic design your tokens preference don't matter (tailwind or handcrafted CSS becomes a personal choice).

BEM solves specificity issue but you still have css in another file. This isn't 1995, the markup/CSS divide was only for modularity. Atomic design + tailwind solves that and gives a lot more. Whether we like it or not, optimizing for LLM completion/generation is becoming more important in our jobs everyday. Productivity is the ultimate metric these days

P.S: Yes, the html assets in the browser gets MESSY but we don't complain about the way our script assets get bundled, minified etc that's for the machine not humans

Thanks for jumping in, really glad you shared this 🙂

This is exactly the kind of example that shows Tailwind can be used thoughtfully and intentionally, which is how it works in most larger projects. You can absolutely build a configurable design system on top of it, and — as in my case — still meet high WCAG audit standards.

Appreciate this perspective a lot!

CapeStart • May 6

Feels like Tailwind became popular for the same reason React did years ago: predictability at scale.

100% agree!

M Saad Ahmad • May 5

For me, it's Tailwind. One of the reasons I prefer Tailwind is that it allows you to see the styling, positioning, and alignment directly in your HTML element without constantly switching between CSS and HTML/React files. That being said, I find CSS to be the easiest and most straightforward solution if you want to quickly establish aesthetics and a visual feel. It’s important to note that CSS is a foundational requirement for Tailwind, so being comfortable with CSS is essential when working with it.

The only downside I see with Tailwind is that it requires some initial setup before you can start using it. You will need to figure out how to integrate Tailwind with the specific tool or framework you’re working with. Recently, they updated the setup process to make it more streamlined, eliminating the need for a tailwind.config.js file. Therefore, you should look up the setup instructions for each tool you are using in your project. Also, the big giant class string is also a downside; you can find it hard to trace what styling and alignment this element in particular is doing.

Even though my focus is on backend development, I have no issues tweaking Tailwind. 😅

192.168.100.1 192.168.1.1

Exactly 🙂 Utility classes have been around forever, but Tailwind really cleaned them up and made them practical at scale.

And yeah, the setup used to be more boilerplate-heavy, but these days it’s much smoother. Honestly, in my side projects I don’t even bother asking LLMs for setup anymore… not worth wasting the tokens 😄

M Saad Ahmad • May 5

Anything to avoid tokens these days 😅.
It's like we went from letting AI do everything to save time to doing it ourselves to save tokens and precious energy that gets consumed along the process.

Saile Dalil • May 4 • Edited

Tailwind CSS might not be "elegant," but it's the ultimate pragmatic tool for those who prioritize speed and team consistency.

Exactly! And if you structure things well, even the “elegance” part becomes good enough 🙂

Ken W Alger • May 4

It’s refreshing to see a direct take on this. Tailwind really shines in a collaborative environment because it provides a shared language. You can look at a colleague's pull request and immediately understand the layout logic without having to hunt down where a specific class is defined in a global CSS file.

Exactly! Tailwind can be a bit stubborn at times, but at least it’s very explicit 🙂

jeetvora331 • May 5

Hi @sylwia-lask , great article. I recently published a quick comparison between Styled Components and Tailwind, highlighting why Tailwind is gaining the edge. Do check it out here

Nice breakdown 🙂 I’ve actually never used Styled Components myself, but this was an interesting read!

Rense Bakker • May 5

I'm on team "if you're going to use frontend libraries for styling, why not go for one that also solves accessibility and fits in with the whole everything is a self-contained component paradigm" (I guess that's a bit long for a team name) Lately shadcn has solved that problem for tailwind I guess. However, I still don't like having to learn a whole new utility class vocabulary, as opposed to just using my css knowledge to style components directly with css in js.

I’ve actually always liked utility classes, so I picked them up pretty quickly because once you see the patterns they’re quite consistent 😄

And yeah, shadcn isn’t as bad as people make it sound. Unlike typical component libraries you don’t have a black box hidden somewhere in node_modules, you own the components in your repo and can tweak them however you like.

That said, I’ve mostly used it in smaller projects, so I don’t have much experience with that stack in enterprise setups.

csm • May 7

I think we should make 2 websites to understand:
i-love-tailwind-sorry-not-sorry.dev (tech stack: vanilla css)
i-dont-love-tailwind-sorry-not-sorry.dev (tech stack: tailwind css)

Sylwia Laskowska • May 7

Haha I love this idea 😂

Sergiy Yevtushenko • May 7

Not an expert in the topic, but: medium.com/codex/html-illiteracy-p...

I can't comment on it, because the content is behind the paywall 😅

Sergiy Yevtushenko • May 8

Sorry, not my content, so I can't open it to everyone. But to read it, you just have to register; otherwise it's free.

Bob • May 8

Tailwind doesn’t replace CSS fundamentals, but it does solve the real problem most teams face: shipping consistent UI fast without fighting specificity and drift. Handcrafted CSS is great when you need full control, but for most product work, Tailwind’s speed and predictability are the better tradeoff.

Exactly this! You start to hate handcrafted CSS as soon as you need to go through three layers of abstraction to understand why the hell this button is green 😅

SeongKuk Han • May 8

But if you’re selling paper clips and organizing a corporate event, you’re probably not baking everything from scratch. You’re ordering something decent that gets the job done.

Agree with this. There was a time people talk about performance in js. for is faster than for each or whatever so on. Now, nobody talks like that. Hardware is developed enough to cover that area. Also, it depends on what kind of projects we are working on, isn't it?

If you're working on a web project, people just say "web development" but each web developer is specialized in a different area, some are good at UI/UX, or writing efficient logics, or structuring, and so on. They are related to each other though. I think this topic is the same.

If a person is working on something where css is important then do css, but if not, maybe better to choose an option like tailwind, to boost their productivity and achieve their goals.

AI comes in, everything is going faster then ever it's been. I think that's why many people are now talking about choosing right tools, or architectures or something. But foundation is anyway important though. I don't know what I'm talking about now, lol, a great post 👍

Exactly! Moreover, users usually don't care about beautiful css. In my experience, they usually care about a good UX. When the site is aesthetic and usability is fine, user is happy 😀he or she doesn't care about handcrafted css.

Marina Eremina • May 6

I really liked the original article, as someone who's invested a lot of time into mastering CSS, I can definitely relate to the idea of writing CSS as a craft! That said, I also really like Tailwind 😅 Exactly because of the Tailwind advantages that you list in the article, especially the development speed. It's all about trade offs, right? 🙂

That's a perfect approach! Why not love both 🥰

Dariamks • May 6

Great take! I totally agree with you.Tailwind isn’t here to replace pure CSS craftsmanship — it’s here to ship faster, stay consistent, and keep large teams from breaking each other’s styles.
At the end of the day, businesses care about working products delivered on time, not perfectly handwritten CSS.Well said 👍

Totally! And there is no reson to complain on it. We can always write perfect css in our own projects 😀

PEACEBINFLOW • May 4

That tension between "speed" and "craft" is interesting, because I think the real tradeoff isn't between Tailwind and handcrafted CSS — it's between different kinds of cognitive load.

With handcrafted CSS, you carry the mental model of a styling system. You name things, you maintain relationships between selectors, you think in abstractions. That's a real cost, but it also forces a kind of deliberate design thinking that sometimes produces better architecture. Tailwind removes that cost — but it removes the forcing function too.

What I've noticed in my own work is that the quality ceiling is actually higher with handcrafted CSS, but the quality floor is way higher with Tailwind. Teams that would otherwise create a tangled mess of specificity wars and dead code ship something coherent. Teams that have the discipline to maintain a clean CSS architecture probably don't need Tailwind in the first place.

So maybe the framework choice matters less than being honest about which kind of team you actually are.

This is a great way to frame it — especially the “quality ceiling vs quality floor” part.

I think that’s exactly why Tailwind works so well in many real-world teams. Not because it’s “better,” but because it raises the floor and makes it harder to create a complete mess. It’s also just faster, and in many projects there simply isn’t time for handcrafted CSS.

Thanks for this perspective — really valuable addition to the discussion 🙂

Martin H • May 5

As I commented on the linked article, Tailwind isn't an either-or proposition. You use it when it makes sense. When you need to write custom CSS Tailwind does an amazing job of making it feel like your Tailwind build.

Totally agree! Using Tailwind doesn’t mean you’re forbidden from writing even a single line of CSS 🙂 Thanks for adding this perspective to the discussion!

Harsh • May 5

Tailwind defenders assemble. 😄

I used to be in the Tailwind is just inline styles with extra steps camp. Then I actually used it on a real project. Now I get it.

What won me over wasn't the speed it was the consistency No more guessing what .card or .btn does across different components. The class name says exactly what it does.

That said, I still miss the feeling of writing clean semantic CSS sometimes. But I don't miss debugging why one margin is pulling from a class three files over.

Team Tailwind here too. Sorry not sorry. 😄🙌

Hahaha exactly 😄 There’s something oddly comforting about those verbose classes.

Honestly, I don’t really miss writing semantic CSS either 😄 Though I do kind of envy how many nice native features CSS has now… I had to struggle through the old days 😂

Chaitanya Burgupalli • May 6

Haven't used Tailwind yet, but if that makes things predictable and efficient, I will take it. Artistry has its place and efficiency has its place.

Exactly, especially when you don't have full control of what other folks write! It's just much more dificult to destroy everything with Tailwind 😅

James • May 5

I’m gonna write another article: 🥰“I don’t care about Tailwind, sorry not sorry” 🤩

That could actually be a great article 😄

Val Saven • May 5

My opinion remains the same: dev.to/valsaven/comment/3292g

Yes, it's not bad for an LLM or a landing page you'll make in an evening and never touch again. For anything else, it's cancer.

Sylwia Laskowska • May 5 • Edited

Very interesting comment. On one hand, calling out the original post as emotional for describing a simple tool in strong terms, and then following it with a long, equally emotional explanation of why that “just a tool” is cancer and we’re already lost… feels a bit contradictory 🙂

There are definitely some valid points in there. Vendor lock-in is real, but that’s true for almost any major choice, whether it’s a component library or a framework. Readability is also subjective. For some people BEM feels cleaner, for others utility classes are more explicit.

Reading this, I get the impression the real issue isn’t Tailwind itself, but overall CSS architecture. Mixing BEM, Tailwind, custom CSS, and @apply will create a mess regardless, and honestly, removing Tailwind from that mix wouldn’t magically fix things.

And the idea that people are somehow afraid to speak negatively about Tailwind… looking at this discussion, it really seems like the opposite 🙂 Most comments are either “I kind of like it” or quite emotional critiques like this one.

Mr james • May 5

Interesting take! I agree Tailwind isn’t perfect, but for real-world projects, speed and consistency often matter more than “perfect” CSS. In the end, it’s about using the right tool for the job.

Exactly! As we say in Poland, “perfect is the enemy of good” 😄

GP • May 4 • Edited

Tailwind is for those who don't know how to code CSS/SCSS. I rest my case.

Well… then maybe it’s a good thing it exists 😄

Christopher Neff • May 5

I call dibs on:

"Sorry Tailwind.....no really."

Haha, go for it 😄 we’re building a whole “Sorry Tailwind” universe at this point!

Ketut Dana • May 6

I promote what I build in three month here

keyyap.com

Sorry to sorry 🙂

Joe • May 6

So many em dashes. Clearly written by AI.

This comment was clearly written by ChatGPT.

titonova • May 4

lmao I can't imagine writing massive raw css for any real project any longer. For those who enjoy the "craft" of writing CSS, good for you!....I have other things to do

Exactly! Many projects are so complex that CSS becomes almost a necessary evil 😄

CitronBrick • May 6 • Edited

Few years back, there was an article on this website from a Web Accessibility Expert
on how Tailwind was against accessibility. I wonder if it still holds true.

It's not about Tailwind itself but about semantics. My app fullfills WCAG norms on AA level, which is confirmed by the audits. So if you do care, you don't have to worry 🙂

Kostas Oreopoulos • May 5

Tailwind is just awful. If you are a programmer, the first principle you learn and should use is DRY.

Tailwind violates that in every possible way.
You do not use CSS as a language but as patches in HTML. That is a monstrosity.

The ONLY place Tailwind is acceptable for me is layout, and only if you do not intend to theme layouts using content queries. Everything else should be in pure CSS.
Buttons, cards, surfaces, and typography should be driven by properties organized in their own files.

We now have the :is and :where selectors and also have @layers to organize the cascade. We have so many tools to make a great layered and easily modified system.

Tailwind is a very bad habit, and you will understand that when you want to recreate your styles. It's practically undoable. If you have 2000 pages, you have to go through all of them to make changes. I am a programmer, and DRY is in my blood. Tailwind is for non programmers.

I actually agree with some of your points, especially around DRY and the capabilities of modern CSS. But I do have reservations about the tone. Instead of simply saying “I prefer a more traditional CSS architecture and control,” it turns into a pretty emotional argument.

That approach works really well if you have the time, discipline, and a stable (ideally small) team. But when you’re dealing with 5 teams, non-negotiable deadlines, and constantly changing requirements, you often don’t have the luxury of handcrafted CSS.

Saying Tailwind “violates DRY in every possible way” also feels like a stretch. Utility classes aren’t exactly a new idea, they’ve been around since Bootstrap days. And the “you have to update 2000 pages” argument doesn’t really hold either . In real projects, you’re working with components, not copy-pasting HTML across pages.

At the end of the day, it’s just a tool. No need to get that emotional about it 🙂 I’m treating it with a fair amount of distance anyway, as the cover photo hopefully makes clear 😄

Kostas Oreopoulos • May 5

I agree my tone is a little bit aggressive, but that's just to show how awful is, for my perception of coding, tailwind.

Tailwind does not treat CSS as a programming language. This alone should be enough
"In real projects, you’re working with components, not copy-pasting HTML across pages." Yes, but small things, like buttons, input elements, animations, etc., are baked into components, and if you do not use a unified css component library, you will be in trouble. Yes we can drive it through tokens and css variables, but is that really a solution? The bookkeeping burden is very big. Even with AI-driven development. Margins, paddings, radiuses ,colors, are fundamentals of your look and should be driven by properties , not utility classes.
"But when you’re dealing with 5 teams, non-negotiable deadlines, and constantly changing requirements." Even if you are dealing with such, you should have some consensus document in order to produce the same quality output. Having one team generate that consesus document and others just applying it, is much better and faster. If something must change, only one team makes the changes and everything just works.

Treat CSS as a language. Yes, CSS was not a proper language, but now it is and is becoming more and more powerful very fast.

Finally, yes, Tailwind is not the first to do utility classes, but Bootstrap started doing it mostly for things like grids and positioning, which was much harder back then, in the pre-flex era and the clearfix utility class. Nowdays we do not have to fight cascade. Use :where for base styling, layer concepts with @layers , create versions on top.