Hacker News Reader

Comment by fbnlsr | Hacker News Reader

I don't get Tailwind. In my book, CSS is here to facilitate the style of multiple webpages by modifying a set of rules, and classes are here to mutualise said rules.

With Tailwind, it looks like you design by writing HTML, which is the opposite of what CSS aims at. So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule.

Every time I've had to work with Tailwind, it felt like a chore and it was an unpleasant experience.

View on HN

> So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule.

Changing the CSS to apply site-wide changes sounds great in theory but after working in front-end since IE6, this almost never happens in practice. You're never certain how the styles cascade and indirectly affect things so you're afraid of changing the core CSS.

Styles isolated to components is a much more scalable approach in my opinion and then it doesn't really matter whether you use Tailwind, CSS-in-JS or scoped CSS (Vue etc).

I do use tailwind and I find it terribly convenient for some things, but this argument still seems to mostly stem from too many people doing css who are not great at designing css and are doing things they really should not.

How will I ever keep track of where I used px-6 and where md:px-4 in my templates and why, without semantic classes? Of course I can then build more solutions around that. Or I can accept that good css design is hard, just like any good software design is hard.

> How will I ever keep track of where I used px-6 and where md:px-4 in my templates and why, without semantic classes?

How will you track that in `.hero-text__sticky-container--primary` vs `.text-with-image__card-primary`?

I wouldn't. I would pick sensible class names. And then I won't care about what's inside specifically, because it's mostly dry.

And then it's still hard, because good css design is hard. Tailwind is not making that easier.

> this almost never happens in practice

…so let's solve that by making it completely never happen?

Let's solve that by switching to a different abstraction that proves to be more useful. In this case, isolation-by-component instead of isolation-by-class.

I'm not the person you're replying to, but I'm in a similar position, and while I'm not in love with Tailwind*, it's successful because it's oriented around components rather than classes. In every project I've worked on, it has been far easier to manage the complexity of components over classes, because components link style and structure together, which usually end up very tightly coupled anyway. This limits the scope of the CSS you're writing a lot, making it a lot simpler to understand what any individual declaration is going to do - you know exactly where it's being used, you know exactly the HTML structure it's operating on, you can see exactly what it will do as a result.

* I use it a lot at work because it's very easy to get something written, but I find the pseudo-CSS DSL irritating if I need to write more complex queries. Something like CSS modules requires a bit more boilerplate to use, but you end up writing real CSS queries, which I find more natural. But this is personal preference.

Let's not spend extra effort supporting a theoretical feature that won't actually happen.

It happens pretty often. I change the style of my websites this way all the time.

Ok, sure. But that's not what you were saying in the comment I responded to.

Because you moved the goalposts. First you said that it “almost never” happens, then that it “won't actually happen”.

Its hard keeping track of different usernames on here.

From my perspective, "almost never" and "won't actually happen" aren't that different. Both indicate that the probability of success is very low. It seems to be, if the probability is already really low, is not worth extending effort maintaining it.

They never said that. I did. You're talking to different people.

Oh, sorry. I'm not looking at usernames.

> You're never certain how the styles cascade and indirectly affect things

Then your DOM is too complex. You're formatting a text document; that shouldn't get you in a position where you lose track of what cascades where. If it is you have a bigger problem than styling.

I agree with you. As a developer I like the separation of style and content. We also gain better readability when the code says "<div class="product-price">199</div>" than a long list of tailwind classes.

CSS styles are also more reusable across different web sites. I can to some degree see that you can increase re-usability when using shared React components, but then you just create technical debt for those who want to test other frameworks

It seems to me that Tailwind is only a semi-scalable solution for those who use React components or similar. But as mentioned above, that causes problems when you want to make other webapps in another framework

Can you explain something about why you prefer the separation of style and content? From my perspective all that it accomplished is making me modify two files (html template and CSS) instead of one.

There are several advantages of separating CSS and code from my point of view.

- I generally dislike inline CSS styles, and the benefits of Tailwind is not enough to overcome that.

- Reusability across systems. At least in mature businesses, they often have CMS systems, different frameworks etc. Using Tailwind kind of encourages everyone to use the same internal React component library.

- Easier to read PR and git logs. Adding a single tailwind class to a component may mark the entire line as changed, and you need to figure out what has changed (including checking the code, because you don't know if that also changed).

- Designers can make changes in CSS without having to learn React.

As soon as you have recurring product prices, you’re encouraged to use @apply to group those classes. In practice, however, you’re using components of some sort anyway, whether in Frontend or backend code, so this isn’t really an issue.

Where have you seen such an encouragement? Even Adam states that @apply was a mistake https://twitter.com/adamwathan/status/1559250403547652097?la....

It’s a completely viable solution for certain situations, say, having a .button class. The things mentioned in that twitter thread have nothing to do with that.

I was commenting on "As soon as you have recurring product prices, you’re encouraged to use @apply to group those classes. ". It's certainly technically possible to create a CSS class. But AFAIK the recommendation is loudly and clearly to use components https://tailwindcss.com/docs/reusing-styles#extracting-compo..., and for good reason.

I follow, but even that part of the docs acknowledges the use cases solved by @apply. No denying it’s a powerful gun to shoot your foot with, but it has its merits. Especially in the OPs context of some bespoke e-commerce CMS, which might not even have a frontend pipeline more sophisticated than grunt or something.

> if you wish to change your design, you'll have to update multiple templates instead of one CSS rule.

this comes up on every tailwind post and it isn't true. tailwind encourages you to not repeat yourself by making reusable components (or fragments etc) instead of reusable classes. that way if I want to see how the button both looks and works I only have one place to look

even if you don't do this, with tailwind you encode your design system (colours, spacing) etc in the config file so even copy pasting everything will get you something consistent

https://tailwindcss.com/docs/utility-first#maintainability-c...

I don't feel this point is strong because when you look at some of the most popular Tailwind components or templates in the ecosystem, such as the one made by the Tailwind people, the Tailwind code is still pretty crazy.

> the Tailwind code is still pretty crazy.

The rendered output is crazy, yes. But this argument applies to every JS framework ever created.

Authoring the code is best encapsulated by components. If you look at the source files available for their paid templates, they are all componentized.

Most JS frameworks are as bad too!

Maybe the issue is that the giant pile of JS mess has created such a disaster that adding Tailwind doesn’t feel like making anything much worse.

I can buy that.

For what HTML is for (documents, web pages, etc.) CSS makes sense and Tailwind seems crazy.

If you’re trying to code an application, for now perhaps React + Tailwind and a mountain of NPM dependencies does actually make sense.

Really I think going back to application coding via something like WASM surely has to replace all that though.

I think your last point has legs, for sure. It makes sense that some other language will compile to wasm and make some app development more straightforward, but I don’t think the end result will be that different.

The web platform is not going to move away from current paradigm without an overwhelming shift in priorities or needs. Wasm still generates html and outputs it on the screen.

My biggest reason to use tailwind is maintainability. Having everything right in front of me with only the tiniest of abstractions, makes it really simple to refactor and maintain. I can confidently delete “CSS” and know it has no side effects. I can cut and paste a block of html and it will render EXACTLY the same. I don’t have to worry that Steve used a generic sibling selector in a CSS file 3 years ago that is screwing with my layout/design.

Is the HTML more bloated than if I had written “normal” css? Yes, but I think it’s worth the trade-off. It’s important that we can agree that their are trade-offs and then it’s up to each project to decide if those are worth it for their use case.

I’ll also mention the actual CSS file is crazy small as well since the tool only generates classes that are actually used in your project. No more ever-growing css that other people are afraid to delete for fear of breaking some legacy page!

> Wasm still generates html and outputs it on the screen

Sure it can. More usefully to my point though, it can also use any of a number of C++/Rust/etc. UI libraries to render directly to a buffer or canvas, which is in my opinion a better long term solution for true applications (vs websites).

When you do that you get total layout control with no need for CSS or worrying about browser defaults.

As a random example here is the Rust egui library demo app running in a browser using WASM (no HTML): https://www.egui.rs/#demo

The speed and “native application” feel are hard to replicate in JS/HTML, as they are just not great tools for the job or rich desktop (or desktop-like) applications.

Why not use the devtools "to see how the button both looks and works"?

In my understanding it somehow abstracts the process of styling a website or whatever and make it easy for people who for any reason don't want to write CSS.

Although I have the sensation many people find hard to write CSS and even despise it (I've read people here in HN who seem to think we should've kept doing layouts with HTML tables and don't agree layout is the job of CSS!) I definitely agree having dozens of classes in your HTML is messy and weird.

Tailwind gives something like a fluent interface.

div.height(maxVH).color(primary).hide()

It’s all stuffed in classes because that’s the limitation given and this information belongs in the markup.

The above is much cleaner to me than: div.class(“primary”). I need to go find primary. What is the parent class. What happens if this isn’t a div now etc. what happens if the parent isn’t a div?

Tailwind just spells it out for you right alongside the layout so that you have all the information in one place.

For me personally, I was able to do things in tailwind I could never do in raw css, but I bet I got better at css as a result.

The docs are also incredible for tailwind. As good as mdn is, you need to already know what you’re looking for.

I can sum up what I like about Tailwind in the following code:

    ``` (in CSS)

    a.link {
      border: red;
    }

    a.link:hover {
      border: blue;
    }
    ```

    ``` (in Tailwind)
    <a class="border-red hover:border-blue">
    ```

It's much easier in Tailwind for me to see locally what's going on with that styling. If I lived in this code all the time, or I was good at structuring CSS, then maybe the first would be more appealing. But I'm a shit at CSS, it always turns into an unmaintainable mess, and I look after a lot of different projects that I might not touch for 6 months. So Tailwind's approach is easier for me.

And when you create an App with hundreds of buttons?

And when the designer change his mind and border-red should not be used anymore?

And what if you have small changes, e.g.

```

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">Button 1</button>

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-3 px-4 rounded">Button 2</button>

```

My solutions to the problems you raise, in order of preference:

1. Not worry about it, it probably won't happen on the projects I'm working on. YAGNI.

2. OK, it's happened. Get some coffee, make all the changes. Can I use a regex? Make the changes incrementally? Delegate it to a junior?

3. This is going to change a lot. Let's make a re-usable component, a named colour like 'primary' (in Tailwind config), or re-usable class like .button-default. The right solution will depend on the requirement.

In styling, I'd rather have 1000 obvious changes than 1 difficult one. The risk of having the wrong shade of red is not high enough for me to worry about abstracting it.

I appreciate that good, full-time CSS devs have much better solutions for this, but those solutions involve being good at CSS as a starting point. I don't have that luxury.

Now imagine that you want to change the border color to yellow. Would you rather change a single line of CSS, or every single link on all your pages?

In tailwind you'd probably use a named color such as `primary` or `border-primary` or something like that, so you still have the ability to change it in one place. I don't really like tailwind myself, but I don't think that's an issue

1. Given the example actually provided here, do you see an opportunity to do that?

2. Suppose you change the example to use named colors. Where does this name-to-color-value mapping live?

****

> I've noticed that moving the goalposts is extremely prevalent on HN, which makes for pretty frustrating conversations (or just reading). And then sometimes it's a tag team. E.g.:

> Person A writes their comment. Person B1 offers a rebuttal. Personal A offers their response. Person B2 offers a second rebuttal that abandons the premise behind B1's rebuttal, and may actually be at odds with it. Person A ends up either deflated or looking defeated.

> It's like the cross product of a Gish gallop and a DDoS.

<https://news.ycombinator.com/item?id=23117242>

As stated elsewhere, if you're using a component based UI, this isn't a problem. You're also free to mix regular CSS with Tailwind.

As for the "git gud" school of CSS, should we also abandon React, Svelte and the like and revert to hand-cranking DOM manipulation like it's 1999...?

Sure, if you're manually editing a large volume of .html by hand, Tailwind is bad news, but given the plethora of static site builders out there (brief shout out to Astro which is excellent), manually authoring individual .html pages seems like masochism.

Tailwind done correctly would have you use another system like react/templates so that you still only have to modify one place.

In practice however I see a lot of copy paste in tailwind html so it doesn't work quite as well in reality.

Sounds like a boring Friday afternoon job, or something I could give to a junior contractor. It's also something that doesn't happen very often on the kinds of projects I'm working on.

If you work with components, you don't have this problem. If you don't work with components, good ol' search and replace and it's done.

If you work with components then why not just use CSS?

In React at least, often you can live with One Component = One File at least for simple components. Adding separate CSS files, as the OP says, causes context-switching.

This is not true in svelte, where a component file can have both a root tag for the component, and a <style> tag that the framework/compiler automatically scopes to this component (and a <script> tag for the code, since you don't have the JSX inversion-of-control principle).

You can utilize the Functional CSS approach to eliminate the redundancy of architecture and behavior across various instances (JSX and CSS). Furthermore, it offers superior performance when compared to OOCSS.

Hopefully your link will be a component, so you only need replace one line anyway.

Then again if your styles are abstracted to a component, your CSS framework is irrelevant!

Why would you use a component for something that's already a built-in HTML element?

I don't know, but a consulting company saddled us with a monstrosity that does exactly this.

Maybe it's some sort of lock-in feature.

One example is if I was using react it would be used to encapsulate a react-router Link and an anchor tag in a component, and use props to differentiate between inbound and outbound links.

Why would you style an anchor element when your browser already has default styles for it?

Because you want it to look different, such as the color being consistent with the rest of your website?

You use border-primary or border-myCustomThing

ctrl+h

Suppose we want to change just one link? Would it be better to make a new class with all the same attributes except the color and apply that to the specific link.

> ctrl+h

Brittle.

> Suppose we want to change just one link? Would it be better to make a new class with all the same attributes except the color and apply that to the specific link.

Why copy the attributes? Just override the one you want to change. You can even use style="…" if you're sure that it's just one link.

The tailwind version is actually horrible, don't do this: you are supposed to style all the links in the same way, as with the css example, not style each link in it's own way; or you will get a link red, another one blue, another one yellow, and your ux will be crappy and your code unmaintainable

Horrible.... for you. For me, it's lovely. My UI productivity and satisfaction has massively increased with Tailwind, and I've been using it for 3 years now.

That isn’t a Tailwind feature though? That’s been like a basic feature of CSS frameworks for 10+ years. Even Bootstrap was going this route way back when.

Who rolls the basic boring CSS classes like border-red or border-primary by themselves? People have been doing it for free for over a decade.

It's too bad that SASS has fallen out of favor. With SASS, that would have been:

```

  a.link
    border: red

    &:hover
      border: blue

```

Yes, I did use SASS before Tailwind (and Compass back in the day), and got a lot of value from them. Where it started to get painful is when I have:

    a.link {
    
    }

    a.another {

    }

    <a class="another link">...</a>

It was easy to fix, but hard to scale the fixes over different codebases, timelines, and developers. That's the problem Tailwind solves for me.

CSS nesting will be available to us mortals (in production) within a year and we might be able to use it just a guess as early as 2026?

https://webkit.org/blog/13813/try-css-nesting-today-in-safar...

That misses the point. This is still worse than seeing all your styles in the place where they apply. SASS/LESS just make it faster and more succinct to write styles in css files rather than in the components in which they live and even more importantly—on the actual ELEMENTS that they apply to.

Fallen out of favor with who?

I think the framework is meant to be used by other frameworks and not by humans.

It is an unpleasant chore if you use it by hand and I have given up on it but I can see that if it's just used in components and then html is not written by hand but made dynamically it could work better.

It's basically a CSS framework for JS frameworks and not for writing HTML.

I like to use tailwind with Svelte since I rarely reuse css but rather the component as a whole. It’s rare for two components to share a class/style

In a recent thread someone explained Tailwind was best used with component frameworks, and that made it make a lot more sense and I could see the appeal.

Still can't see it. Once you do components CSS gets much simpler, what's the point of a layer on top?

It’s actually one less layer. My layout and styling are finally together, and well documented. I don’t mean in the same file like a .vue file. I mean they are TOGETHER.

I disagree, tried it with a small custom component lib in our company. It was a huge overhead to add options for e.g. a button-component.

You can use Tailwind on top level and it is easy. But as soon as you have complex components with sub-elements, the styling gets really complicated.

It was easier to add component specific classes and define the css within the component. You call then the component with the classname.

It is easier to write CSS with Svelte.

It’s easier to poop rainbows with unicorns.

It's easier to verb with nouns.

Reply on news.ycombinator.com