Hacker News new | ask | show | jobs
by blowski 1042 days ago
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.
5 comments

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?