Hacker News Reader

Comment by cosmotic | Hacker News Reader

Tailwind smells like using a style attribute but with properties that are fewer characters. It's fully embracing what everyone said to avoid. What am I missing?

View on HN

One huge difference is that you can use media queries with TailwindCSS and you can't with the style attribute.

I think the best defense of Tailwind's approach is from Adam Wathan in this post.

https://adamwathan.me/css-utility-classes-and-separation-of-...

I think one key difference is the way people are developing re-usable components now. Since you only define it once, the benefit of re-usable class names isn't as important as co-locating and scoping your CSS for ease of use. You want as little cascading as possible in that circumstance so again, traditional benefits of classes aren't as compelling.

I use a flavour of BEM naming with an approach I call Contexts and Components to achieve concise, low inheritance CSS and I can see how Tailwind can get you similar benefits and solve for some stuff traditional CSS has a hard time solving within frontend frameworks.

I am still fighting picking it up, but that is the use case I see for it, component driven workflows.

I'm a non-designer developer who nonetheless does some frontend work, so with that grain of salt, here's my take:

What everyone said to avoid was actually just wrong. Semantic CSS failed. Tailwind (or utility classes in general) is the best way to implement a reasonably-maintainable and properly-specified version of putting things in the style attribute.

You're likely missing 2 things: 1) you probably haven't delved into Tailwind on a non-trivial project and 2) the nuanced difference is between infinite possibilities (style attribute) vs. discrete, "hard-coded" options (Tailwind classes). Think of strings vs. enum values when describing "types" in an application.

Apologies if this seems snarky but it would be far more useful if you could explain your point rather than a generic condescending "[you] haven't delved into Tailwind on a non-trivial project".

I don't think they were being condescending – there's a lot of material out there on why Tailwind is good, it's easy to find via Google, but nothing beats trying it out.

If you don't want to do that then you could watch some of Adam Wathan's screencasts on YouTube where he uses Tailwind to recreate pages or build new ones.

https://www.youtube.com/c/AdamWathan/videos?view=0&sort=p&fl...

The benefits are "you don't suffer from <some set of problems I've never suffered from, even on large projects>". The cost is cluttered markup and what appears to be impossible reuse.

This smells a lot like every other tech bandwagon. It's the best thing since sliced bread until wide adoption exposes all the flaws and we go back to what proceeded it.

I'm giving myself additional time before I get into it for this exact reason.

Something seems fundamentally off about this library, but I can't pinpoint what.

I dunno. The vibe I get from it is very similar to React. The excitement, the arguments for and against, the focus on some kind of 'separation of concerns' purity that isn't ultimately that convincing.

I waited a while before bothering with React, but based on my positive experience with that particular 'paradigm shift' I gave Tailwind a shot. So far it's been really, really pleasant on a moderately-sized project, so that's hopeful.

I don't see the point in dismissing it, based on all that. We didn't go back from React to jQuery and Backbone, we moved forward from it.

That said, it's fair enough and probably smart to wait and see at this point if you don't have the luxury of experimenting. I totally get that.

That's a very fair comment, but I do sort of agree with the person you're replying to.

Others here have provided reasons why Tailwind is great, and many comments just center around how it's at least not a bad idea.

But for myself, I read a lot of these arguments before and wasn't convinced until I used it in a fairly big project. To some extent it's hard to explain the benefits because once you get past the more 'ideological' issues (separation of concerns, etc.), it's really much more about how it affects the flow of day to day work. I don't think any arguments would've really convinced me, but because of the excitement around here I gave it a shot, and was convinced by seeing how my project grew without many of the usual CSS issues I'd run into (as well as the convenience of just not having to switch to a stylesheet file most of the time).

But I do understand how frustrating a comment like that can be.

It does. Using inline style attributes is basically a good idea when using a component framework, except for missing features and questionable performance. Tailwind solves that.

There is an influential presentation from, i think, someone on the react team that started the whole CSS-in-JS thing. It just advocated for using inline styles. I can‘t seem to find it.

React and Vue have special handling of the inline style attribute to make it more pleasant to use, so it‘s not been fully discouraged for a while.

That was Christopher "vjeux" Chedeau's "CSS in JS" talk:

https://blog.vjeux.com/2014/javascript/react-css-in-js-natio...

Well it is like that, except instead of picking any attribute possible, you're picking from a pre-selected list which have been saved as variables, i.e. utility classes. And it also provides workarounds for the things that inexplicably don't work in inline CSS, like media queries.

What's the problem with style attributes? I would use them instead of regular CSS if I could add pseudo-attributes and make them responsive. Since I can't I use Tailwind where that's possible.

> What's the problem with style attributes? I would use them instead of regular CSS if I could add pseudo-attributes and make them responsive.

Imagine styling a table row. That is one style attribute. Now imagine styling a 100 tables rows. That is style attribute duplicated a 100 times. Think of the amount of unnecessary bandwidth consumed to load that HTML file with 100 duplicate style attributes. Not only does it slow down page load times, it also slows down page render times.

Now if you add selectors to style attributes then it solves the above issue altogether. But, then you are just re-inventing the wheel. Instead of CSS in a separate file you now have the same functionality but all inlined in style attributes.

The render time point is misleading. It can be slower but even on low end devices, CSS is so insanely fast, you would need an HTML source in the tens of MB's range to cause noticeable performance problems. Also, CSS classes do make that even less of a problem. Inline styles are fast enough, and classes are faster by default, so Tailwind wins there.

Page load times are interesting, but again, unless you're loading an insane amount of data from the server, it will never be a real issue.

Some sort of component architecture solves the problem you bring up w/ duplication. You should never be writing the same thing 100x over. JS frameworks all render 100's of the same component with the same attributes and performance is fine for 99% of real use cases.

The downsides for Tailwind all revolve around personal preference and how your team organizes a project. There is no performance hit (unless you ship the entire un-purged CSS file to production, even then, it's minimal).

> you would need an HTML source in the tens of MB's range to cause noticeable performance problems.

What? Do you ever leave the city? It seems like that’s an unsupported use case any many developers minds.

Okay now I'm growing curious, where in hell do you regularly find HTML sources that weigh tens of MBs?

My point is that it's a problem loong before you reach tens of MB, once you leave the dense cell towers and fast hard links found in a city.

That's a good point, but tailwind is primarily suited for component based architectures.

So in this situation you would have a <my-row /> component, which would contain the tailwind classes. This reduces load time as duplication is eliminated, but I'm not sure it would reduce the render time.

Style attributes have very high specificity so they basically preclude using normal CSS files (they would mandate every line include !important)

This is misleading, !important is not required to use inline styles.

They still cascade normally like CSS classes... see this example:

    <div style="color: red">
      <p>red text</p>
      <p>red text</p>
      <p style="color: blue">blue text</p>
    </div>

Ironically, it's actually complex CSS classes and long selectors that produce high specificity, which then requires even more specificity to override and eventually the dreaded !important

The parent is not talking about inheritance. They are talking about specificity.

If an element has a style attribute that sets the color, it will override every single CSS/Style-element style that also sets the color, unless the CSS/Style-element style also includes an !important.

The stockholm-syndrome of the few users positively recommending something that changes their development workflow slightly when they were bored of doing things the old ways.

Ah yes, few users. Which is why this post was on top of HN frontpage.

And yes, definitely it's just that it changed the development workflow slightly, not at all that it brings new possibilities and a much better developer experience.

apart from the many points the other repliers raise, you cant write media queries in style attrs. making precise changes to the exact dom elements for responsive design becomes a great deal less a house of cards with tailwind.

Reply on news.ycombinator.com