👋 Introduction
When I first started learning frontend development, styling a webpage felt overwhelming. Writing long CSS files, naming classes, man...
For further actions, you may consider blocking this person and/or reporting abuse
I always read these tailwind articles hoping that one day one will answer the one question that actually matters: We know inline styles are bad; why should we go back to using them?
I'm sure most of us know about the short-term strengths of TW over separate CSS; but we also know that
style=""has all the same strengths or more. And there are good reasons we aren't using that anymore.Yeah, I see what you mean. But inline styles are just more work. Tailwind is like inline styles done right—faster, cleaner, and easier for the whole team. Unless we miss the table-layout era, I’d stick with TW. 😅
Inline styles aren't bad because they require more typing; they're bad for very deep structural problems that I haven't seen TW address in any way.
Table layouts are also an interesting thing to bring up; because tailwind seems to mirror all the fundamental problems with tables.
Makes me wonder if 10 years from now, people will look back on tailwind as another one of those cringe ways we used to build websites, while doing the next iteration of the exact same thing rather than just use CSS.
yeh, every developer has their own perspective and preferences.
My take is this: inline styles are like duct tape on a web app, while Tailwind is like LEGO bricks. It's not replacing CSS, but offering a faster and more consistent way to use it.
In 10 years, we may laugh at today's trends, but I doubt we'll laugh at clean, maintainable design systems. Just like React builds on top of plain HTML to make development easier (see my blog on this), Tailwind is simply a smarter way to use CSS.
Sure, but all you've said is that tailwind somehow gets around all the inherent problems with inline styling, but not how it does it. Every time I've looked at TW it seemed to just have all the same problems with a different syntax.
Sure Tailwind is built on top of CSS, so it inherits both its strengths and weaknesses.
The difference is that Tailwind knows how to manage those problems. Inline styles sit directly in the HTML and can’t handle things like pseudo-classes (:hover), media queries, or consistent design tokens.
Tailwind, however, uses predefined utility classes tied to a centralized design system (spacing, colors, typography). So while it might look like inline styles at first glance,
under the hood it’s structured, reusable, and far more maintainable.”
I think you're somewhat misunderstanding the problem with inline CSS.
There are many features nowadays that can't really be used with inline styles; but the knowledge that inlining styling inside the markup predates many of these features.
Again, the problem is with inlining styles, not with the specific limitations of using
style; the problems result from inlining styles directly in the markup rather than separate CSS files. Tailwind, to my knowledge, doesn't really address these problems in any way whatsoever. That's what I'm asking about.Exactly—that's the whole point. The real issue lies in inline styles directly in the markup, not in external CSS. And that’s where Tailwind is fundamentally different.
I think there's just a bit of misunderstanding here, Otherwise, your understanding of the issue is solid.
How is Tailwind different though? You're still inlining all of your styles directly in the markup, just with the extra indirection of a DSL.
It may look like inlining, but Tailwind isn’t injecting actual style rules into the markup like inline CSS does. Instead, it applies predefined utility classes that reference centralized, reusable CSS scoped, optimized, and purged at build time.
its not just about extra indirection of DSL, it’s about maintainability, consistency, and scalability.
Yes, as I said, it replaces inline CSS with a custom DSL; but it is still, fundamentally, inlining styles, just like CSS though. All the other adjectives are kind of just noise:
I agree, and again, tailwind is still inline CSS just like
style, and I'm still looking for why on earth it would be any more maintainable or why the fundamental problems with inline styling wouldn't apply to it.If you think Tailwind is just inline CSS with a fancy alias, you’re missing the entire point of utility-first design systems.
Inline styles are one-offs—hard to maintain, impossible to scale. Tailwind builds from a consistent, shared system. That’s not ‘just styling in markup’—that’s structured CSS applied efficiently. Big difference.
Well, yea, if you scroll up, basically my entire point is that I'm wondering if I'm missing something but nobody has really explained it yet.
But Tailwind is inline styling though. And yea, that should make it hard to maintain and impossible to scale. Yet tailwind users seem very convinced that it doesn't. I'd love to know how that is, because it doesn't seem to make sense.
Yes, but inline CSS is exactly the same. It builds from a consistent, shared system, aka. CSS, which is implemented by browsers directly, rather than Tailwind, which is just a different system implemented on top of CSS.
What's structured about it? If you want to make the text in a paragraph bold, you go to that tag and set it to bold; whether you do so by some tailwind class or css attribute, you're still inlining the style "bold" in your markup.
Neither approach is more or less structured than the other, they're just different DSLs for the same job. But, correct me if I'm wrong, tailwind still isn't any more declarative or reusable than inline css in any meaningful way.