Live data from Hacker News

Tailwind CSS marketing and misinformation engine

nuejs.org

91–100 of 125 posts

Re: Tailwind CSS marketing and misinformation engine

#91
post #84
post #66

Earlier quoted context omitted.

> because I only write it once, in my Button component. Unless of course you have several similar buttons with only minor differences between them. Maybe copy-paste? And then you have to slightly tweak your buttons... Or add conditional effects or dark mode and the complexity explodes, just on a simple button.

The same is true of CSS classes, though - there you have the same choice between reuse and duplication. Do you have .button-primary, .button-secondary, etc, or do you use modifiers instead? The combinatorial complexity is inherent in the design of these sorts of components, you won't get away from it just by using a different tool to write your styles.

But CSS handles it much better, which is the point.

You separate it into a .button class, and then further specialize it by adding more classes (like ".button .button-primary").

With Tailwind everything is duplicated, but with CSS you can move out the common parts.

Re: Tailwind CSS marketing and misinformation engine

#92
post #91
post #84

Earlier quoted context omitted.

The same is true of CSS classes, though - there you have the same choice between reuse and duplication. Do you have .button-primary, .button-secondary, etc, or do you use modifiers instead? The combinatorial complexity is inherent in the design of these sorts of components, you won't get away from it just by using a different tool to write your styles.

But CSS handles it much better, which is the point. You separate it into a .button class, and then further specialize it by adding more classes (like ".button .button-primary"). With Tailwind everything is duplicated, but with CSS you can move out the common parts.

Nothing holding you back doing exactly the same with Tailwind.

Re: Tailwind CSS marketing and misinformation engine

#93
post #91

Earlier quoted context omitted.

But CSS handles it much better, which is the point. You separate it into a .button class, and then further specialize it by adding more classes (like ".button .button-primary"). With Tailwind everything is duplicated, but with CSS you can move out the common parts.

Nothing holding you back doing exactly the same with Tailwind.

Of course, the solution to Tailwind's problem is to refactor it with CSS classes...

Re: Tailwind CSS marketing and misinformation engine

#94

Tailwind is write only, you’re not supposed to read it or maintain in. Want to change some property? Delete the entire class=“” attribute and start anew. Take that primary button example from the article - no one is claiming that it’s readable, especially when there are hundreds of primary buttons throughout the app, each with a slight variation. This works great for marketing or landing pages, or other use cases whe…

> especially when there are hundreds of primary buttons throughout the app, each with a slight variation.

If you're repeating monstrous groups of styles like the one in the blog post, but with a slight variation for each, then you're tremendously far out in the weeds and almost definitely shouldn't be using tailwind

Tailwind really only works for a component-based framework (like React, Svelte, Solid, etc.), where you define a component representing a button, and give it props to map to the 'minor variation' you want.

That way if you need to support e.g. a new device class, you just add the relevant class names there and don't have to revisit your entire codebase.

This isn't apparent at all when inspecting the source of a site using tailwind, because as far as the rendered markup is concerned, these are getting repeated (and the verbosity of the output is absolutely a fair criticism)

But if you're writing it, and organizing your components in a sensible way, then the problem you mention doesn't exist.

Re: Tailwind CSS marketing and misinformation engine

#95

Being a designer who does his work inside code, Tailwind is a nightmare. I hand off my design files, the developers do their thing. But then, maybe I want to tweak things after a review, or the design system changes, so I have to do a sweeping change to those buttons. Now I need to touch dozens of jsx/tsx files around the platform and make humongous pull requests, and the result is often dozens of merge conflicts. If…

> Now I need to touch dozens of jsx/tsx files around the platform and make humongous pull requests, and the result is often dozens of merge conflicts

This can be mitigated by enforcing one-classname-per-line, but it's admittedly not the standard

Re: Tailwind CSS marketing and misinformation engine

#96
post #91
post #84

Earlier quoted context omitted.

The same is true of CSS classes, though - there you have the same choice between reuse and duplication. Do you have .button-primary, .button-secondary, etc, or do you use modifiers instead? The combinatorial complexity is inherent in the design of these sorts of components, you won't get away from it just by using a different tool to write your styles.

But CSS handles it much better, which is the point. You separate it into a .button class, and then further specialize it by adding more classes (like ".button .button-primary"). With Tailwind everything is duplicated, but with CSS you can move out the common parts.

And to do this with a component framework and tailwind you give your component some props that customize it.

With CSS you also have to worry about the cascade way too much, so while you are doing much of the same work with Tailwind, you get the nice benefit of inlining the styles which will actually apply to your component. Yes, you still have to think about organization and how to make different styles apply to variants of the main class, but it's so much easier to not also have to worry about how cascading rules might apply and constantly check different rules for specificity and overrides

Re: Tailwind CSS marketing and misinformation engine

#97
post #91
post #84

Earlier quoted context omitted.

The same is true of CSS classes, though - there you have the same choice between reuse and duplication. Do you have .button-primary, .button-secondary, etc, or do you use modifiers instead? The combinatorial complexity is inherent in the design of these sorts of components, you won't get away from it just by using a different tool to write your styles.

But CSS handles it much better, which is the point. You separate it into a .button class, and then further specialize it by adding more classes (like ".button .button-primary"). With Tailwind everything is duplicated, but with CSS you can move out the common parts.

It is completely possible to do that with Tailwind and components, I do it all the time. I'll create a Button component that takes parameters like `mode=primary`. The Button component contains a `button` element with some common classes that apply to all buttons (padding, borders, shadows, etc). Then depending on the parameters, I'll append other specialised classes (usually colours).

The only thing you have in CSS that is harder when working with Tailwind is overrides - e.g. "this component is normally blue, but it's green if this class/parameter/attribute is set". That said, even when I'm using CSS, I tend to find overriding, except in the simplest of cases, usually causes problems, because now I need to make assumptions about the order of declarations that are difficult to make in a codebase maintained by multiple people over several years. For that reason, in the button case, I would typically make it so that the different modifiers (.button-primary etc) are mandatory when using the .button class.

Re: Tailwind CSS marketing and misinformation engine

#98

Being a designer who does his work inside code, Tailwind is a nightmare. I hand off my design files, the developers do their thing. But then, maybe I want to tweak things after a review, or the design system changes, so I have to do a sweeping change to those buttons. Now I need to touch dozens of jsx/tsx files around the platform and make humongous pull requests, and the result is often dozens of merge conflicts. If…

> ...I have to do a sweeping change to those buttons.

Why aren't those buttons encapsulated in reusable components or templates?

What sorts of changes do you need to make where this is an issue?

Post reply on HN