Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS's problems are Tailwind's problems

colton.dev

Post reply on HN
Print view View original

61–70 of 179 posts

Re: CSS's problems are Tailwind's problems

#61

Post by squidbeak »

Alupis wrote: post #32
micromacrofoot wrote: post #6

Earlier quoted context omitted.

I can't believe people find even half of this acceptable, do they never use a browser inspector in their work?

If you write enough CSS for a site... eventually you end up building utility classes anyway. Now, you re-invented Tailwind... but in your own proprietary way that nobody else understands. Tailwind takes the inverse approach. The example posted by the parent above is completely unambiguous - what you see is what you get, and it's done the same way everywhere Tailwind is used. You can read the component's styles and un…

There's a big difference between using utility classes for utilities and using utility classes for everything.

Re: CSS's problems are Tailwind's problems

#63

Post by coltonv »

M4v3R wrote: post #18

I can't believe this article made it to the front page. It feels like the author has some personal vendetta and just doesn't care about the facts. > Tailwind decided to burst on to the scene and become the default styling solution for all modern web development despite taking each and every one of these problems, exacerbating them, and applying them to places that didn't have them before If Tailwind is so bad and has…

> If Tailwind is so bad and has literally no upsides then how on earth it managed to take the frontend world like a storm? In authors eyes frontend developers have to be either stupid, or ignorant, or both if they decided to choose such a bad solution en masse.

Please read the entire article before commenting. I have an entire section on this. I don't think frontend devs are idiots and never said they were. Tailwind offers global constants configuration out of the box, which is the most important problem people are looking to solve, which is why I think such a flawed library has so much success.

> To me (and probably many others) using Tailwind is all about speed and reducing file hopping. If I ever need to adjust style of anything it's always trivial - just locate the component and adjust the classes. Writing new code is so much faster because I don't need to think about what classname to invent for every single html element I would like to style, I don't need to create separate definitions, files etc. for them. For my particular workflow it's a huge win.

Part of my point is that this already exists with inline styles. In react for example you can set up some plain JS constants and import them to do inline styles. And you get the benefits of type checking and other JS features. That's not a perfect solution either, and it's not one I'd endorse past hobby projects, but my point is that Tailwind just takes an existing pattern and makes it worse.

> This is just plain wrong. You can install Tailwind autocomplete, checks or eslint rules in literally any editor/IDE of your choice and you will never have an issue of misspelling the classes. Most solutions will even autocomplete your custom classes defined in your Tailwind config.

These are okay but trip over themselves and cause issues if you have any plain CSS class usage, which is necessary in certain situations in my experience.

Re: CSS's problems are Tailwind's problems

#64

Post by 827a »

My complaint with tailwind is that it doesn't do a good job of working well with components. E.g. if I have a component that wants to set a default background color for a button, but makes it customizable, I might think to do something like this?

    export function MyButton({ className }) {
      return 
    }
But that doesn't really work, because ultimately we've just provided both the bg-red-500 and bg-green-500 classes, and we're leaving it up to the precedence rules in the browser CSS engine (which I'm sure are consistent, but that feels like a no thanks from me)

So instead I end up doing something like:

    export function MyButton({ bg = "bg-red-500" }) {
      return 
    }
But that also feels unsatisfying, because while that prop is named 'bg' you could literally provide any tailwind class you want through it; there's no way to constrain it to only allow tailwind classes which are functionally interchangeable with bg-red-500.

Anyone else run into this and have a nicer solution?

Re: CSS's problems are Tailwind's problems

#65

Post by jakelazaroff »

dminik wrote: post #53
coltonv wrote: post #7

Earlier quoted context omitted.

I'd really appreciate reading the whole article before commenting like this. I point out the problems with CSS-in-JS and do not wholly endorse it, and I do recommend using simple CSS as a solid solution for many people.

I reread the conclusion. I apologize for jumping to conclusions so fast but ... You specify like 4 approaches: 1. Tailwind - apparently awful 2. Regular stylesheets - also not good 3. Inline Styles - some flaws 4. CSS-in-JS - minimal flaws when using vanilla-extract Reading through the article, my first thought was that you really like vanilla-extract. When I got to the conclusion section, and the first line is "I li…

vanilla-extract has zero runtime impact, right? I personally prefer using CSS modules (by a lot) but I don't see a huge difference between the two.

Re: CSS's problems are Tailwind's problems

#66

Post by wwweston »

This is a novel take that I think genuinely adds something to tired tailwind discourse:

> I think the most important factor in Tailwind's success is that it does one thing very correctly: it demands the developer who installs it set up a config file that lays out all codebase-wide style constants: colors, margin sizes, fonts, border radii, etc. Writing individual styles that do not use a pre-configured constant from the config file is clunky in Tailwind. This is a good thing, an unironic win for Tailwind. More than anything else, this is what a large codebase with multiple frontend devs needs: a rigid set of global constants that everyone is strongly incentivized to use.

I’m still considering its merits, but it at least goes beyond the “How I learned to stop worrying and embrace tailwind’s standardized soup” vs “I can’t stand this, it goes against every organizing principle I’ve found useful” familiar dichotomy.

Re: CSS's problems are Tailwind's problems

#67

Post by chuckadams »

cogman10 wrote: post #34
chuckadams wrote: post #25

Earlier quoted context omitted.

You can override classes, not so much inline css.

Is anyone ever going to override the "px-3" class? You can also change styles through javascript if you really want to. It just seems like we've lost the entire reason for css in the first place when every css attribute gets turned into it's own class.

Special cases in layout are a thing, happens a lot once you start nesting third-party widgets. So yes, there may be enough of a use-case for overriding px-3 that it wouldn't make sense to specifically omit it as a utility class -- to say nothing of it being useful as a utility class to begin with.

I only sprinkle in the very occasional tailwind class via UnoCSS. I don't have the fire in me to dig trenches for either side of this battle that some people want to make all this into.

Re: CSS's problems are Tailwind's problems

#68

Post by hombre_fatal »

Since Tailwind looks obviously bad on first pass with all the class spam, I'm more curious to see someone steelman Tailwind.

I have some ideas, like how the dead code elimination + granular but consistent classes lets you build novel components that are still consistent with your UI which might be essential for making a 3rd party component library work.

I've been using Bootstrap since it came out 15 years ago but it never developed a 3rd party component library. I assume because it doesn't have the same sort granular building blocks for building novel components.

Then again there are also component libraries like https://ui.mantine.dev/ that don't use Tailwind.

I sadly never really looked into these modern options since when I want to build something, the last thing I want to do is dick around with a whole new UI solution vs Bootstrap muscle memory.

Re: CSS's problems are Tailwind's problems

#69

Post by jakelazaroff »

827a wrote: post #64

My complaint with tailwind is that it doesn't do a good job of working well with components. E.g. if I have a component that wants to set a default background color for a button, but makes it customizable, I might think to do something like this? export function MyButton({ className }) { return } But that doesn't really work, because ultimately we've just provided both the bg-red-500 and bg-green-500 classes, and we'…

Yeah, use CSS variables. I wrote a TIL on doing this exact thing (customizing a button's background color from outside) with vanilla CSS: https://til.jakelazaroff.com/css/dynamically-change-styles-f...

In Tailwind you could probably replicate this with custom variants or whatever they're called.

Re: CSS's problems are Tailwind's problems

#70

Post by coltonv »

dminik wrote: post #53
coltonv wrote: post #7

Earlier quoted context omitted.

I'd really appreciate reading the whole article before commenting like this. I point out the problems with CSS-in-JS and do not wholly endorse it, and I do recommend using simple CSS as a solid solution for many people.

I reread the conclusion. I apologize for jumping to conclusions so fast but ... You specify like 4 approaches: 1. Tailwind - apparently awful 2. Regular stylesheets - also not good 3. Inline Styles - some flaws 4. CSS-in-JS - minimal flaws when using vanilla-extract Reading through the article, my first thought was that you really like vanilla-extract. When I got to the conclusion section, and the first line is "I li…

I do think you should look at it further! It's a great library, though I can see why people won't like it for the reasons I mentioned in the article (i.e. having to build and enforce your own constants system). If you are going to use something like Tailwind, you're already okay with putting styles in Javascript and adding a bundler plugin, the two main "leaps" required to use something like vanilla-extract.

Since the style sheets are extracted into CSS and do not contribute to JS bundle size, I'm not sure visceral CSS-in-JS reaction is justified when it comes to vanilla-extract. Tailwind is still basically CSS-in-JS, but more of a hybrid of CSS-in-JS and CSS-in-JSON. Could you elaborate on your frustrations with CSS-in-JS as it pertains to vanilla-extract, the one CSS-in-JS library I recommend?

Post reply on HN