Live data from Hacker News

I don't recommend Tailwind CSS

en.andros.dev

71–80 of 178 posts

Re: I don't recommend Tailwind CSS

#71
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.…

Don’t you need to keep more context in your mind if you use Tailwaind to make .button_checkout_special_page_cta_widget while staying somewhat consistent?

Could you give us a few examples with and without Tailwind, including CSS variable and compose in preprocessors?

Re: I don't recommend Tailwind CSS

#72

Saying "unless you use @apply" invalidates this article for me. Everyone knows that @apply only exists as an escape hatch, it is not supposed to be used, except for when it's necessary like for compatibility with libraries that declare their own classes that you need to override. The most commonly repeated point in the article is "escape hatches bad" and I think that's completely absurd. Of course you want escape hat…

It makes no sense for me that @apply is frowned upon. It's what makes Tailwind actually kinda usable for me. Without it, markup looks like line noise full of boilerplate that's hard to modify in a systematic way.

I think what Tailwind actually needs is more abstractions, not to discourage the use of the sole abstraction @apply

Re: I don't recommend Tailwind CSS

#73
post #7

As a 26+ year frontender, years ago I was against it on so many levels. Until I tried it. Never looked back. Also, inheriting projects with someone else’s code is fine. Just a quick look at the central config and you’re good to go.

Tailwind looks bad on "paper". It violates a lot of "best practices". It is ugly. Yet in reality it works. It gets the job done. It is fast to work with. Constraints are known to enhance creativity.

Semantic CSS is Java AbstractBeanFactoryBuilder. Or as Steve Yegge put it, Kingdom of Nouns.

Tailwind CSS is Python dictionaries where you don't create one user-order-deliver-date CSS class for every Noun you have.

Re: I don't recommend Tailwind CSS

#74
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.…

What? I don't even know what you're talking about, and I've written mountains of vanilla CSS code in big projects.

Re: I don't recommend Tailwind CSS

#75
post #69
post #66

Earlier quoted context omitted.

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.

Almost none of that is specific to Tailwind though, you can take any design system in CSS with or without JS and make the same argument right?

Re: I don't recommend Tailwind CSS

#76
post #61

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…

That’s exactly how I’m doing this using tailwind and daisyui though, so I’m not sure what point you are trying to make?

My global tailwind.css defines two sets of css vars for the light and dark theme, and it all gets applied globally with a single line in my root html template. I don’t need to touch my markup. Tailwind simply compiles this down to a single css file in the end.

Re: I don't recommend Tailwind CSS

#77

Saying "unless you use @apply" invalidates this article for me. Everyone knows that @apply only exists as an escape hatch, it is not supposed to be used, except for when it's necessary like for compatibility with libraries that declare their own classes that you need to override. The most commonly repeated point in the article is "escape hatches bad" and I think that's completely absurd. Of course you want escape hat…

It makes no sense for me that @apply is frowned upon. It's what makes Tailwind actually kinda usable for me. Without it, markup looks like line noise full of boilerplate that's hard to modify in a systematic way. I think what Tailwind actually needs is more abstractions, not to discourage the use of the sole abstraction @apply

Using @apply defeats the entire purpose of Tailwind. The point of it is to localize styling alongside the markup. If you're using @apply then you're constantly context switching from your markup to your CSS files while working.

There's plenty of ways to manage the bevy of classes you need. First step is making use of components to deduplicate stuff. Then in those components, use a library like class-variance-authority aka "cva()" which allows you to set up complex named presets for your components (like size="small" or color="primary" and things like that).

Re: I don't recommend Tailwind CSS

#78
post #69

Earlier quoted context omitted.

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.

Almost none of that is specific to Tailwind though, you can take any design system in CSS with or without JS and make the same argument right?

What do you think tailwind is?

It's a utility to generate deduped/treeshacken css classes - according to a config file the parent mentioned

It's not some grand framework or something.

It's literally doing exactly what the grand parent said. Define root css variables, and generate the applicable/used css classes that were used in the code

Re: I don't recommend Tailwind CSS

#79
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.…

Yes.

you just add `checkout` class or `big` class to your button. or use `.checkout-page .button` to modify look/size of your whatever button on the checkout page if it's style is truly unique and not used anywhere else.

Post reply on HN