Thats exactly what this component library does: https://daisyui.com/components/button

If you want to do in "raw" tailwind (i.e. without this component library), you can use layers to create your own component classes, e.g.:

  @layer components {
    .btn {
      @apply inline-block px-4 py-3 text-sm font-semibold text-center uppercase transition duration-200 ease-in-out rounded-md cursor-pointer;
    }
    .btn-primary {
      @apply text-white bg-indigo-500 hover:bg-indigo-600;
    }
  }

If it's just one class per property, you could just type out the CSS. Using emmet in IDE is probably faster than finding the tailwind classes with autocomplete.

>If it's just one class per property, you could just type out the CSS.

You can, but then it rarely happens that you want the CSS to be fixed in that way for all time: the brilliance of tailwind is that you get resposniveness just by adding a few more classes. You cannot do that with inline CSS.

This is the one pro-tailwind argument I can agree with. Sometimes I’ll use their shorthand md: & sm: in @apply in place of media queries. The advantage is that they remain local to their relevant selectors.

Makes me think- all I would really want is to be able to have multiple values in css. Maybe something like .

.card { width: 5rem md: 10rem; }

Snap… am I on to something?

Sass/Scss let you nest media queries inside of selectors years ago.

And the result is html and css that is easier to read later. I’m so fast with CSS that Tailwind inevitably slows me down as an app scales.

With Tailwind, if you write out something like that more than once or twice, you're really supposed to bundle it together. Either as a plain CSS class, or a component in your framework of choice.

I suppose a library of common elements is a good thing to have, but the reason I like Tailwind is that I can use the utilities at first and then easily gather them together as plain CSS classes as and when that makes sense to me.

But if you're going to hide away CSS inside a component, why not just use inline CSS? What does Tailwind add to this?

1) A set of a classes with consistent names for scales, colours, etc. You're not working with hex codes or pixel values. It's a more writable and much more readable syntax than inline styles.

2) It has variants for hover, etc (e.g.: class="bg-black hover:bg-white"). AFAIK you can't do that with inline styles.

3) I find it plays nicely with a workflow where I start out not knowing exactly what I'm doing, which is almost all of the time. I can smash ahead and do things in the class="" of each tag, then as I notice that I'm repeating myself, I grab small chunks of the class list and put them in '@apply's in a CSS file. Bottom-up, liek.

The class lists are just a lot more manageable than inline styles. They're copy-pastable and really easy to read when you get used to it, as long as the lists aren't too long.

Whenever I read a comment like this I feel like talking to someone who’s never used Tailwind nor written inline CSS. How do you write inline CSS for pseudo-classes like :hover, :focus, :disabled? Media queries for breakpoints and dark mode? Not to mention more advanced features like divide-, space-, group-hover:, etc.

There's a pretty good article by Sarah Dayan about this, which was written in response to one of the more recent Tailwind dramas on Twitter:

https://frontstuff.io/no-utility-classes-arent-the-same-as-i...

Well for one you cannot use all CSS features inline, some of them are pretty important. Then there are also bad performance implications of using pure inline styles.

But in terms of structuring your code, there are related concepts in other areas of programming:

The most general concept applied here is stratification or layering. You want to decompose your code into more general pieces so you can use those pieces to compose the actual solutions.

Example: Say you wanted to write a compiler. It typically much easier to simplify, AKA decompose the compiler into a scanner, parser, analyzer, optimizer, emitter etc. The users of your compiler probably don't care that you decomposed and layered your code. But you do care, since you can reason about your code in terms of small/local problems. Maybe you don't stop there. Your scanner can be stratified further, so you can easily build evolve and reason about it.

This is the primary thing these types of libraries do. They give you generalized building blocks that have compositional semantics that make sense. You can use their sane defaults or generate them from scratch using a design system.

Secondly the atoms are discretely defined. You're not dealing with all possible values for each property but with sets that you can join/compose. The generated classes have this little mini-syntax that you first need to get used to a bit, but after a while you'll easily remember the prefix schema of your classes (Tailwind's documentation site is also very well made). Tailwind cross joins the atoms for you, but then also deletes all the classes you didn't use in your project.

a very underrated feature of Tailwind is it's excellent documentation with immediate search. Want italic text? In straight CSS, how long will it take to look up is it font-style: italic; or text-style: italic or text-italic: true ? Tailwind's docs make it virtually instant. Even more impressive with flex and grid layouts (is it justify-items or align-items, etc). I find that Tailwind reduces the time from "idea in brain" to "implemented on page" by about 90%, now multiply that by dozens or hundreds of individual page elements. (to be fair, I don't do a ton of front end so I forget the CSS syntax quite often)

This is the worst "feature" ever.

What's the point in spending 20 hours learning some custom interface that's only used in like 5% of projects and will probably be gone in 5 years, when you could spend 30 hours learning the standard that's been around for decades and understand every library for years to come?

Just learn CSS, it's not that hard.

You... don't? Spend 20 hours learning, that is

I never sat down for hours to learn it. I just started using it. Most of the classes were very intuitive with a working knowledge of the box model. For anything else I just searched the docs or even better, got the VSCode plugin to suggest the correct one

It's not a custom interface. It's just classes. It's got a type of syntax, sure, especially for media queries but it's not much different than "learning" the classes from bootstrap

It's literally just CSS but abstracted as convenient classes as the name "utility classes" implies already. I don't understand why people keep telling others to learn CSS instead. I also hate dealing and writing CSS cause it's cumbersome and unwieldy and this is a much better way of styling my HTML and getting immediate feedback

As others commented, inline CSS has downsides. But there are libraries out there that allow you to write a block of CSS alongside your component that are neatly packaged into a CSS file, like Styled Components (https://styled-components.com/).

Because you don't have to use it in a component system. It's not a case of hiding it away, it just has a system for building your own css library kind of thing if you want to

Tailwind gives you rules and constraints.

Yes, the way I use it is with Svelte. I've created a list of components in Svelte (buttons, links, dropdowns, tables, etc.) I think with how tailwind makes you html look (very full of classes), it is perfectly matched with a component based framework.

That way you get the full tailwind experience without the tedious rewriting of components.

I agree with the positive sentiment, but a cynical take might be that we've basically found our way back, traveling in a circular pattern.

It looks like Tailwind and Tachyons are useful tools but they do have a sweet spot, and I've run into the annoyance of 20+ classes in my tiny projects as well. Descriptive

Real changes to the landscape have been made along the way:

- Flexbox and to a lesser extent grid are grokked by many

- People are much more willing and able to use CSS variables

- Shadow DOM encapsulation and other methods of isolating styles from one component to another are well explored

- there's some stuff on the horizon where people are JITing here and there and writing custom compositors ("Houdini" and related tech)

But I'm not sure there have been any large paradigm shifts in CSS over the last 10 years, and Tailwind no matter how successful it's been commercially and in the headspace of developers seems to have been largely a very useful somewhat passing obsession.

I see this not as a replacement, but as a novice choice. As noted in the documentation, you can use tailwind classes to customize existing components but if you do not want to you can use it like bootstrap. Even for building a quick prototype which can be made to look good in future is a use case for this.

I want to note that I was talking about tailwind vs bootstrap and others in the abstract, less so about DaisyUI specifically.

What lead me to make the comment was the discussion point that "btn btn-primary" was so much more useful than 20+ tailwind classes. I agreed (it's something I have come across as well), but

It's clear that Daisy UI will get you up and running quickly and there are lots of similar projects out there that do things like this, but the meta discussion around whether we're going in circles or if we've actually moved forward and found a nice mix between what was the bootstrap style (1-2 classes that do all the work) and tailwind/tachyons (5-10+ classes that do the work).

To make the discussion less meta -- is the future things like DaisyUI? Bootstrap like classes but with the outlet for overriding not being manual CSS but actually being tailwind-style classes? In the past it was Bootstrap + your special large class/baked in styles, but in the future maybe it's "btn btn-primary box-shadow" or whatever, clearly a middle point of sorts

I'm not a frontend developer so I've been watching this from the outside over the years of reading HN.

The impression I got is that Tailwind is essentially CSS 2.0 with warts ironed out (sorry for the unpleasant mixed metaphor):

A) CSS / Tailwind: lots of little 'atomic' classes describing individual visual properties. Easy to understand, easy to customize, but slow to read, slow to get started, with plenty of stuff to learn

B) CSS frameworks / Tailwind components: fewer classes declaratively describing the component's role (eg 'btn-primary'). Quick to get started, elegant to read, but prone to abstraction leakage and trickier to bend to your own exact specifications

There's always been a need for both kind of tools for different projects, in the same way that e.g. network programming may involve anything from bit-banging commands to high-level protocols.

Over the years CSS frameworks kept improving, but CSS was much slower to do so - although it acquired flexbox, grid, etc., the language limitations stayed, and they were bad enough to spawn SASS/LESS out of a genuine need.

Tailwind saw a ton of hype and adoption because all the developers who had always wanted to go the (A) road now had a well-designed set of simple classes they could use with a lot fewer footguns, plus a bunch of developers who had adopted (B) because it was the road that had all the momentum suddenly realized that they probably wanted to use (A) once it was made less painful.

DaisyUI and similar projects don't do anything that Bootstrap didn't do for CSS, but by building on top of Tailwind it means that, when your project or resources grow and you want to move from (B) to fully customizing your style in (A), you will be able to write your individual little graphic touches in Tailwind instead of plain CSS.

I tend to use it with some sort of component system - vue/react/svelte - so writing the classes out once doesn't bother me.

I actually like it, as looking at the code I can see exactly what it does. 'btn-primary' doesn't convey anything to me. 'rounded text-sm font-bold py-2 px-3 bg-indigo-300' I know exactly what that is going to look like.

I also appreciate the removal of classes not needed if using a build step - much nicer to have a small css file that has exactly what you use, rather than a bootstrap style kitchen sink

so why not just use bootstrap? I'm new to web development, but I thought the whole point of TailwindCSS is that it is more customisable than Bootstrap.

What if you as a beginner can start using Tailwind immediately with this library and can learn tailwind's utility classes at your own pace when you need to customize anything?

I'm not sure about this path, but it might be good for a beginner.

Yeah, this seems more like the combo of ease of Bootstrap + the extendability of Tailwind.

It is hard to breakout of Bootstrap defaults.

Both libraries have pros and cons.

No. No. It's a link disguised as a button. Stop doing that.

Why? A “create” button that takes you to a creation page is still a link to that page and should be a link. It looking like a button indicates an action that the user understands. It is accessible, semantically correct, and follows accepted design conventions. What is the problem?

> Why?

Because there's an expected built-in behaviour to these elements.

> It is accessible, semantically correct, and follows accepted design conventions.

There's nothing accepted about disguising a link as a button. Especially when it literally does no action except, you know, linking to a different page.

Though, of course, there are ambiguous situations, especially in the context of PWAs. But code examples are not an ambiguous situation.

I think that ship has sailed, I really don't think that average users expect a button to 'do something' (in the sense it submits a form or something). Going to a different page /is/ 'doing something' as far as users are concerned. Certainly not the internet of old where a form was a form, and a link was a link.

An average user has no idea what's going on in modern software anymore, to be honest. Nothing is what it seems and is redesigned every couple of months

On the GitHub front page there is a sidebar with a second level heading for “Repositories”. Next to the heading there is a:

    <a class="btn btn-primary" href="/new">
      New
    </a>

Below the heading there is a list of repos which had a recent activity by you. Each list item has a link to an that repo.

   <a class="dashbord-underlined-link" href="/namespace/repo">
     namespace/repo
   </a>

There is a substantial difference between these two links. One takes you to a location, the other one starts a process which ends with an action.

As a user you are not going to be clicking the “New” button everyday. Maybe once a month, maybe once a year. So you are likely not going to remember where it is from the last time you clicked it. If you don’t find it when you need it, you will get frustrated. It needs a lot of visual weight relative to the other links in this nav section. Giving the same weight as a button is a reasonable decision.

Eh, unless an app is a SPA (where you attach event handlers to buttons to run client side validation or something like that) it’s way simpler to have a form route to another resource via a link. But users think of them more as actions than links, so its perfectly reasonable to disguise a link as a button.

edit: I said “form”, but I meant page. Forms actually use buttons!