DaisyUI: Tailwind CSS Components

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.

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...

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.

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 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.

> 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.

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.

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

For anyone else reading, this is also stated in the Tailwind docs: https://tailwindcss.com/docs/styling-with-utility-classes#us....

How are you going to style your components, if not via CSS classes?

The hole point of having a Component-Library is to reuse Components. And a component is markup, style and functionality. Not only the CSS. E.g. you want to use the same Button-Component all over the place in your project and not re-declare <button class="btn btn-secondary">text</button> again and again in your project. If you think about more complex Component like a sort able table, it becomes more obvious.

Tailwind is a set of utility CSS classes you can use that tend to guide you into writing CSS that looks like it "fits" together. E.g., consistent gaps if you use `gap-1`, `gap-2`, etc., rather than a hodgepodge of "hmm did I use margin-right: 2px or 1em or what" that can emerge in a large CSS codebase with many developers. We can use a `m-1` or `p-1` class to define a base padding, and as long as everyone knows that `1` is the amount of space to use by default, everything will generally look like it fits together.

Later, you can optionally redefine what `1` means if you want more space in your design. In a way, using tailwind can be like variablizing your CSS at compile time (in a faster way than just using writing and using CSS variables).

For a lot of things, using just 1-3 tailwind classes on a div is sufficient for many common tasks, e.g., `flex flex-row gap-1` boom done. You can put this directly in the HTML, and is considered "fine".

An example from DaisyUI's site is:

``` <button class="bg-zinc-100 border font-semibold text-zinc-900 text-sm px-4 duration-200 py-2.5 transition-all hover:border-zinc-300 hover:bg-zinc-200 focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-zinc-900 active:translate-y-[0.5px] inline-flex gap-2 rounded-sm active:border-zinc-300 active:bg-zinc-200 active:shadow-none text-center align-middle cursor-pointer border-zinc-200 dark:border-zinc-700 dark:bg-neutral-700 dark:text-zinc-300 dark:hover:border-zinc-950 dark:hover:bg-zinc-950 dark:focus-visible:outline-zinc-200 dark:active:border-zinc-950 dark:active:bg-zinc-900"> ```

This is everything needed to make a button look nice in tailwind, and obviously it would be insane to copy+paste this every time you want a nice looking button in your HTML (not to mention the byte size, it's just unreadable).

The best thing to do is define a `.btn` or `.button` (usually I might avoid `button` DOM level selector for future flexibility) and encapsulate these styles as a semantic component in your .css file. You can write them with raw CSS or `@apply bg-zinc-100 border ...;` using tailwind style @apply.

This is what DaisyUI provides you, a shortcut to common nice looking UI components.

Imo the main benefit of Tailwind (or any other style-in-JS approach) is parameterization. Styling often changes based on runtime state. Mapping runtime states to css classes/ids (or scss functions et al) is brittle and doesn't scale well.

Yes, they'll typically have a UI component that accepts props and may have some internal state.

DaisyUI is operating at the style layer, so you might use it to achieve the visuals for your UI component (regardless of how you achieve your UI component, be it React/Vue/server-rendered/etc)

I'm suggesting that just because you have a UI component, it doesn't mean you should be sending 30 tailwind classes for this button across the wire (in a server-rendered approach), and DaisyUI is 1 mechanism to achieve this with approximately 1 component CSS class.

Sure, you might make a `<Button>` UI component (assume React), but if it embeds 30 classes in it, when you server-render this, every button on your page is contributing ~30 classes worth of bytes to the payload sent across the wire.

The need for a component abstraction is the problem?

`<button class=“steve”>` will render like every other steve button, subject to context, cascading down the rules, and applied globally.

You don’t need anything for this but CSS and HTML.

I think you're agreeing with me. DaisyUI is 1 implementation of a standardization shortcut so you don't have to e.g., develop your own button, dropdown, modal, nav, etc (whatever you are interested to consume from DaisyUI)

The docs up through version 3.x explicitly called this out as not recommended and a poor choice, but the justifications were... sort of lame. "You'll have to come up with class names, your css bundle might be bigger, etc". I did read a more technical github issue on @apply vs theme() which called out the apply behaviour as doing a bit more than expected. I don't recall 'theme' being a thing in earlier tailwind versions, but I'm not an expert at it, so I might have missed that.

IIRC the creator of tailwind might have been against @apply too, but it didn't seem like a good recommendation to me

It's not a full circle, because you don't end up back where you started. Inline styles have many well-known missing features, like pseudo-classes and media queries.

Yeah it's turning the crank another half turn. It's insane to me how the webdev ecosystem keeps reinventing itself over and over and over again, trying to solve their previous mistakes without ever reflecting on and learning from why those issues existed in the first place.

Don’t forget it adds the “feature” of a build step that literally greps the source code to see which style shortcuts you used, or seemed to use, so it can render them into CSS definitions so they can be turned back into inline styles.

And why is that a bad thing? It might be the case that bgcolor and cellpadding stopped being used because they didn't support media queries for example, not because they were inline styles.

Not really. I think I'll do that and put it on my Medium or something.

As I see it, it's something like Bootstrap that's built on top of Tailwind which an architecturally valid approach in that it decomposes into clean layers. Personally I could see the appeal of Tailwind in how it encapsulates CSS into graphically meaningful classes, defining classes that are semantically meaningful out of those is a great idea.

Somebody who likes Tailwind would have an easy time specializing DaisyUI to look exactly like what they want. For that matter you could make Tailwind with DaisyUI easily. Their examples look great and I could totally see using DaisyUI instead of Bootstrap on my side projects, though my current ones have real back end problems that need solving and reworking the CSS isn't on the agenda any time soon.

Off topic, but is there a term for the opposite concept?

Something like "Decisions acquire a greater illusion of planning and deliberation the further into the past they were made".

Feels like assuming there is a reason can be just as damaging as assuming there isn't one.

I've been writing CSS by hand since the late 90s. I resisted Tailwind for a long time, but I tried it on a pet project and I get it now. It doesn't fundamentally do anything that you can't do in CSS already, but it sort of "quantizes" the DX such that the vast majority of the CSS you'd usually end up writing boils down to a set of conventions.

You can still write your own CSS as needed (and probably should, for some of the more esoteric Tailwind cases), but stupid stuff like flexbox directives and padding/layout that you do literally everywhere become a lot easier, especially with things like the Tailwind VSCode plugin which provides autocomplete, reflection on defined variables, and linter errors for duplicated or incompatbile expressions.