Hacker News Reader

Comment by erokar | Hacker News Reader

I've used Tailwind on many projects at work for about a year now. I do not like it.

Tailwind seemingly affords an easy way of writing inline styles, but it 1) clutters the HTML, 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that), 3) uses names that can be similar but are not identical to CSS properties and feels like a bad abstraction.

If you use something like Svelte, where you can write local CSS within a component I fail the see the benefit of Tailwind. For me Tailwind is the most ill-conceived frontend tech I've had to use in later years.

View on HN

> 1) clutters the HTML,

Or, it makes your HTML far more representative of the state of your application, rather than having to open up a CSS file and match to the class name + whatever madness you have going on in your SASS with mixins and conditional style logic.

> 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that)

Blindly following DRY is dogma. Not everything can (or should) be a component. The number one mistake I see with new React developers is "over componentization", where everything is a sub component, and now I'm digging through 5 different files to work on a feature. Use the "rule of three" here. The first time you write something, don't even think about making it a component. The second time you write it, start planning how to generalize. The third time you need it, make it a component.

Copy/pasting is OK. Declaratively laying out your UI rather than generating it through configuration is OK. Having no abstractions is better than a bad or even mediocre abstraction.

I mainly work in Svelte, and I use tailwind's @apply all the time in my local component.

Mainly I get the benefits from setting the tailwind config file for things that apply across my components.

Not all of my repeatable markup lives as utilities, e.g. <a> and <buttons> — I define those classes in the scss file. Oh yeah, combining scss and tailwind also gives lots of composability options

Component local CSS is fine too, as long as you use a theme system to constrain CSS choices. I think in practice they are pretty similar, but I personally way prefer the ergonomics of Tailwind.

I actually love Svelte, but generally feel much more productive in React, in part, because Tailwind seems to work better with it.

What do you mean by tailwind works better?

Also, this is the first I’ve heard anyone proficient in both consider React more productive! I’m curious, do you think that has more to do with the amount of experience you have in React over Svelte?

Possibly, but Tailwind makes things so much faster for me. React has "better" developer tools. Perhaps I'm less proficient in Svelte, Rollup is still cryptic to me, and I haven't taken the time to use Vite/Kit yet.

Oh I think the other thing was Svelte doesn't work as well with Typescript (or I couldn't figure out how to make it work as well). I wouldn't get type hints in situations where I would with React.

Perhaps I just didn't take the time to get things set up properly. If you can link a Svelte project that uses Tailwind and Typescript I'd love to give it a clone and see if things work better.

Regarding productivity, I don't think I'm "less" productive in Svelte, especially for smaller apps. I think I've been really conditioned by React and have an easier time splitting out components and making things more modular, which makes a big difference with larger apps.

Reply on news.ycombinator.com