Hacker News Reader

Just because you have Tailwind in your codebase doesn't mean you can _only_ use Tailwind. I often use a mixture of both when it makes sense. The Tailwind classes are often terser. Tailwind is not great for all things.

> which emulates class based styling

IMO, what DaisyUI does is how you are meant to be using Tailwind. You aren't supposed to use _only_ TailwindCSS classes in HTML directly (although you can). It's faster for prototyping, then once the prototype solidifies and becomes a pattern, you can extract your long tailwind string into a nice utility class.

It happens to use things like `@apply gap-2` internally in its src, so that if you want to override "how large the gaps are" in Tailwind, Daisy will also inherit that override.

I've been complaining about this for years, even writing an article on it. When the article initially made it's rounds on HN it was divisive. People seem to have cooled off a bit on tailwind since then, which is good, but you still see it being dumped into new projects, or originating things like this that attempt to build a facsimile of what we get "for free" in the browser

https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...

Yes to all you have written here. That helps me feel less insane.

If React had scoped styles like Vue has, I don't think tailwind would have gained such traction. Lack of scoped styles in native CSS has always been a fundamental shortcoming (always, except for the brief moment in like 2013 when @scope was spec'd and implemented, only to be snuffed out shortly thereafter). But it's coming for real now, maybe...

We've got @scope back now, and, while it's not exactly the same as it was in the early part of the 2010s, it's still pretty good, as it let's you set both upper and lower bounds for a block of css. Being able to say "these selectors don't apply below this point" is immensely powerful, letting you build donut styles for components very easily

It wasn't quite ready when I wrote a sort of follow up article[1] about new CSS features largely eliminating the need for scss, but it's basically baseline now.

My personal new favorite feature is color mix and the other color compositional functions. You can do really neat tricks with them, current color, and variables, that are otherwise impossible, even with scss

[1] https://pdx.su/blog/2023-10-25-css-is-fun-again/

Yes, Tailwind's CSS reminds me of the same unoptimized HTML tag soup that editors of the 2000s era web used to spit out. Tailwind is created by designers for designers. It's perfect for how designers think about layout and works well for them in a world with strict design specs.

Unfortunately, it's also incredibly bespoke and since it's found in most recent well designed templates, engineers must also learn how to work with it. Something 5 years ago that would have died from its own complexity weighing it down for the new shiney, is now kept alive by the ease at which AI can keep it going.

The original motivation of CSS was the cascading aspect of it. During its development, the web was largely seen as a web of documents. Style sheets tried mimicking how traditional publishers style their documents, books, etc. There is also a need to reconcile document styling applied by the user agent, the site author, and possibly other sources. This is where cascading comes into play.

Problems start to occur when using a system designed around traditional publishing to declare the layout of a web application. This is why CSS eventually gained layout-related functionality (flex, grid, container queries, etc.), among other features.

Tailwind provides two things out-of-the-box that make it convenient for building web applications: (1) it comes with a ready-to-use style system; (2) it allows styles to be colocated with markup. The second point is mostly useful for building UI components. Everything strictly related to presentation can be stored within a single file.

Before using Tailwind, I was a strong advocate of CSS modules (and I still strongly advocate for CSS modules if one wants to avoid Tailwind). With either approach, one can achieve isolated styling between components. Repeated styling or markup is a strong indicator that you should extract something into a component.

The first thought that came to my mind reading the DaisyUI website was "Is this an April Fool's joke?". I wouldn't normally post something like that, as it's entirely unfair to the hard work and dedication that someone has put into this. However, I think it captures my surprise by how smack on the nose this is in terms of the spiral of tech abstractions - this is exactly what CSS was designed to solve, and things like tailwind appear to be leading to people forgetting that.

Had the same initial reaction - have we come full circle to Bootstrap 20 years later?

But after playing around with their theme builder[1], I think there's real value here - you can quickly spin up a custom-ish set of Tailwind components. I'd rather it output an actual component library though more like shadcn.

[1] https://daisyui.com/theme-generator

The whole tailwind thing feels like an emperor has no clothes thing

I built apps for a long, long time without Tailwind, just using CSS, sometimes Sass. And I still do at work because our build system doesn't support Tailwind compiler. But for all my side projects, of which there's a few, I use Tailwind. It's just so much easier. I don't see how this experience is compatible with a Emperor's no clothes situation.

Tailwind is better understood as a more powerful replacement for inline styles like <p style="color:blue;">, rather than a less powerful replacement for the full functionality of CSS.

Tailwind is an implementation of "Atomic CSS," and the biggest arguments to use Tailwind are the arguments in favor of Atomic CSS, which are well-known.

> But then we got Tailwind, which uses CSS classes to emulate the pre-CSS behavior of specifying styles at a hyperfine granularity everywhere.

I think it's unfair to tailwind, the point of it that it provides you sensible defaults to choose from. It's perfect for hobby write-once stuff, prototyping, then once you're happy, create a class and @apply.

It has to work like this to provide fast feedback cycle during development. Why tailwind folks insist that copying and pasting it final product is okay, I don't know.

Most of my Tailwind objections have gone away with the availability of CSS layers. Now using a library for a utility layer, which can surgically override your component layer, makes perfect sense. And using a library for that component layer that adheres to the same design token API as the utility layer also makes sense.

One benefit of tailwind is that while all of the classes look like they set properties with fixed values, they are actually almost all controlled by variables. This makes it easier to retain a coherent design during redesigns. Doing the same in CSS is absolutely possible, but tailwind is terser.

Sure, but you want to do this also with your markup and have one source of truth not many.

And I still prefer using tailwind and daisyui to build my applications.

> And now we get DaisyUI, which emulates class based styling on top of a toolkit that emulates attribute based styling on top of the class based system of CSS.

I mean, no. Daisy doesn’t emulate anything, it is class based styling. It happens to have a build system that that emulates attribute based styling on top of the class based system of CSS, but Daisy’s classes appear in your CSS as normal CSS classes.