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

I don't recommend Tailwind CSS

en.andros.dev

Post reply on HN
Print view View original

61–70 of 178 posts

Re: I don't recommend Tailwind CSS

#61

Post by afavour »

Honestly I tire of this debate. Both sides have good points have both choices are valid.

I don’t particularly like Tailwind because I know and like CSS. It’s powerful, Tailwild stands in the way of me doing what I want with it. But in this thread you’ll see people saying “it’s great, I haven’t had to learn any CSS in years” and that’s not an invalid viewpoint.

Tailwind is to CSS what React is to the DOM, if not even more so. If you’re working on a ton of boilerplate UI it lets you get the job done without having to learn the core technology being used. For better or worse that’s where the industry is today.

All I would say is that solely Tailwild folks owe it to themselves to look at modern CSS sometime. The arrival of variables in particular is a gamechanger and makes things like palettes and theming far more intuitive than it ever used to be. When I see how Tailwind handles dark mode I cringe. With raw CSS you set a color palette as variables then override them with a media query. The element itself doesn’t need to have anything added.

Re: I don't recommend Tailwind CSS

#64

Post by 9dev »

guessmyname wrote: post #18
9dev wrote: post #10

This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…

The fact that “text-red-500 text-green-500” resolves by stylesheet source order rather than anything visible in the markup means the “locality of behavior” promise quietly breaks exactly when you compose components dynamically, which is why tailwind-merge exists at all, and needing a runtime dependency to answer “which of my two classes wins?” is a real design smell, not a bikeshed.

That is kind of my point, though—you don't need tailwind-merge, really. There are two cases it solves:

One, adding classes from the outside to an encapsulated component with its own, internal classes, to make sure the outside-applied classes take priority. Either use the !important modifier on them (`ms-auto!`), put the components into a container div with the classes for layout concerns, or even better: Figure out why you need to make styling changes to a component that cannot be expressed via props. I would generally recommend components to not have outside-element styling like margins in them anyway, which most often fights with positioning later.

Two, merging prop-derived styling with base styles - for example for a `size: 'sm'|'lg'` prop. It's tempting to just use tailwind-merge here:

  const classList = tailwindMerge(
    'p-4',
    size == 'sm' && 'p-2',
    size == 'lg' && 'p-6',
  );
But that isn't necessary at all: The better alternative would be to use data attributes for visual concerns and built-in or aria attributes for interaction states. There are almost always element attributes that can represent what you want to have correctly, and data- where there are not. Then, you can just add a class accordingly:
And you'll end up with easier to maintain components that derive their styles from the CSS cascade alone.

Re: I don't recommend Tailwind CSS

#65

Post by tibastral2 »

tibastral2 wrote: post #22

What is funny with your article is that you talk about tradition, when actually these traditions are based on assumptions which are themselves based on beliefs like : "separation of structure and style are a good thing". But this belief is only true if the language to describe the structure is html or js which creates not reusable pieces of style/structure. But when you go for a different approach where everything is…

I don't recommend css. Css is BLOATED. And tailwind makes it a little less bloated, but it's still not strongly typed, and not very re-usable, especially in code.

But your approach is from the past man, really... .btn is not reusable among pages / projects / etc. => it's always different, and when you understand that specificity wars is the main problem of css, you will not want to use your idea again.

It LOOKS cool to have a inside your html. because it's more readable. But it's NOT explicit. You fragment truth into different pieces. and it makes it IMPOSSIBLE to test things in isolation.

One last thing. Using all the "last features" of css is just putting you in a place where you depend on the browser carriers to handle things for you when I prefer personnaly to rely on myself and my craft. But that's a personal one ;)

Re: I don't recommend Tailwind CSS

#66

Post by afavour »

pixard wrote: post #29

I see you have a .button, cool! So did you load the entire context of your project into your mind, and calculate every possible iteration of kind, size, color etc this button may have? And once you did that, did you come up with a semantically correct naming scheme that is clear and will not succumb to the inevitable .button_checkout_special_page_cta_widget a particular page will end up requiring? No? Neither did I.…

It’s funny, as someone that’s been using CSS for decades I don’t really know how to respond because the scenario outlined here is not one I recognise. My button would be a , so no, I wouldn’t have a .button class, it’s superfluous.

What I would have is:

- a global palette specified via CSS variables

- overrides for dark mode etc specified at the global level so I don’t have to worry about it at the component level

- CSS module files so I specifically don’t need to care for the context of my entire project, just the classes for my current component

Of course, you stopped thinking about CSS a decade ago so you don’t know about any of these improvements. Which is fine but it strikes me as a little strange to be so boastful of ignorance.

As someone who has barely touched Tailwind I’m genuinely curious: if you wanted, say, a consistent border color for use across your project how would you? Are you defining a class name in JS for use with $framework_name? And do you really style each component separately for dark mode? Repeating the same modifiers over and over?

Re: I don't recommend Tailwind CSS

#68

Post by maelito »

What's so strange with Tailwind users is how insistent they are to impose it to codebases they don't know. I've never seen this even with vue vs react.

People that didn't write lines of code on this project, or so.

A few months later, your codebase has very long lines of HTML with classes that encode a whole programming language as strings separated by spaces, and barely no component anymore, nor semantic CSS tags.

Re: I don't recommend Tailwind CSS

#69

Post by Aeolos »

afavour wrote: post #66
pixard wrote: post #29

I see you have a .button, cool! So did you load the entire context of your project into your mind, and calculate every possible iteration of kind, size, color etc this button may have? And once you did that, did you come up with a semantically correct naming scheme that is clear and will not succumb to the inevitable .button_checkout_special_page_cta_widget a particular page will end up requiring? No? Neither did I.…

It’s funny, as someone that’s been using CSS for decades I don’t really know how to respond because the scenario outlined here is not one I recognise. My button would be a , so no, I wouldn’t have a .button class, it’s superfluous. What I would have is: - a global palette specified via CSS variables - overrides for dark mode etc specified at the global level so I don’t have to worry about it at the component level -…

You just make a design system in your tailwind.css, following the documentation. You can optionally use something like daisyui if you do not have designer skills or the time.

That handles consistent sizing, spacing, text, colors, dark mode, and anything else your design system needs. It all compiles down to css in the end, so no runtime overhead and gives you the superior tailwind dx during development.

Re: I don't recommend Tailwind CSS

#70

Post by azangru »

cpursley wrote: post #6

My sass customers don't even know what css means, it's fine. Nobody cares as long as the things they expect are on the page in the right position and font is readable.

Do your sass customers know what javascript is or how it's different from java? Does this mean developers shouldn't care either?
Post reply on HN