Live data from Hacker News

Tailwind: A Utility-First CSS Framework

tailwindcss.com

41–50 of 106 posts

Re: Tailwind: A Utility-First CSS Framework

#41

Earlier quoted context omitted.

> "holy hell this is the worst thing I've ever seen" This is so true. All the classes in HTML source look so ugly and verbose when you first see it. At first I dismissed the framework and wondered how someone could think this was a good idea. I kept seeing it pop up, and the comments were always positive, so I put in a little more effort into understanding how it works. Eventually I decided to try it, and within 5 mi…

The problem I have is: what if I want to (for example) add a style or take it away from all my buttons? It's going to be a lot of manual fiddle, or is the idea that hand written sites are wrong to start with and I should be using generated code?

https://tailwindcss.com/docs/examples/buttons

Re: Tailwind: A Utility-First CSS Framework

#42

Earlier quoted context omitted.

> "holy hell this is the worst thing I've ever seen" This is so true. All the classes in HTML source look so ugly and verbose when you first see it. At first I dismissed the framework and wondered how someone could think this was a good idea. I kept seeing it pop up, and the comments were always positive, so I put in a little more effort into understanding how it works. Eventually I decided to try it, and within 5 mi…

The problem I have is: what if I want to (for example) add a style or take it away from all my buttons? It's going to be a lot of manual fiddle, or is the idea that hand written sites are wrong to start with and I should be using generated code?

This is a totally real problem and one of the things that put me off of using some of the existing utility frameworks before creating Tailwind.

With Tailwind, we don't try to pretend that you will never need to write any CSS, and instead embrace that fact and give you as much tooling and guidance as possible on how to extend the framework the way it was intended to be extended.

In the situation you're talking about, you would extract a "component class" using Tailwind's `@apply` directive to enforce that the component followed your design system:

https://tailwindcss.com/docs/extracting-components

Then you could update all your buttons at once by making changes to that component class.

The key with Tailwind is that it encourages a "utility-FIRST" workflow, not a "utility-ONLY" workflow. Build your UI with small primitive utility classes, and extract components only when you start to experience painful duplication problems.

Re: Tailwind: A Utility-First CSS Framework

#43
post #12

Earlier quoted context omitted.

Isn't that basically the same thing as inline styles? Not quite, for a few reasons: Inline styles don't respect media queries, which basically rules out responsive design Inline styles aren't limited to pre-defined options, meaning you can still end up with 90 different shades of blue) Inline styles cause specificity issues, since they trump separate stylesheets. Inline styles don't support print-specific styles. Inl…

So what happens when your design changes and suddenly all your white buttons need to be off-grey? You change the class on 700 components?

https://tailwindcss.com/docs/examples/buttons

Re: Tailwind: A Utility-First CSS Framework

#45
post #12

Earlier quoted context omitted.

Isn't that basically the same thing as inline styles? Not quite, for a few reasons: Inline styles don't respect media queries, which basically rules out responsive design Inline styles aren't limited to pre-defined options, meaning you can still end up with 90 different shades of blue) Inline styles cause specificity issues, since they trump separate stylesheets. Inline styles don't support print-specific styles. Inl…

So what happens when your design changes and suddenly all your white buttons need to be off-grey? You change the class on 700 components?

There seems to be a misconception that you need to go all-in on utilities when using a framework like Tailwind.

If you have 500 buttons using the exact same set of classes, you should of had a button class in the first place. Almost all my projects have their own button and form input classes for this exact reason!

Where utility-based CSS frameworks really start to shine is the other 75% of your codebase, where you're inventing clever class names, only to end up using them once.

This is also why Tailwind calls itself a utility-FIRST framework. Build things with utilities, and extract components to classes when the need arises. Avoiding early abstractions provides a lot of value (in any programming language for that matter). Not having to invent a name for every single piece of UI also saves a ton of headaches down the road.

Re: Tailwind: A Utility-First CSS Framework

#46

Author of Tailwind here! If you haven't worked with a library like this before, I promise your gut reaction will be "holy hell this is the worst thing I've ever seen" (it was my reaction too!) You really do have to try it to shake that impression. If you need a bit more convincing before you're willing to try it, I wrote an in-depth article a while ago that documents my journey from a "semantic classes"-loving HTML/C…

This [1] is one of the best articles I've read describing the issues and thought processes around the complexities of structuring css. But the suggested conclusions are exactly where I start to have problems. Take this recommendation for example:

  .align-left {
    text-align: left;
  }
This is a very reusable class, of course, because it is literally just css but with a different name. But that's what always ends up happening. The lowest common denominator for reusability in css is so low, that you often end up with ridiculously simple classes like this, or close, basically re-inventing css with a different syntax. The new challenge becomes learning this new language and how to compose it.

The core issue with CSS is that it has divergent architectural characteristics simultaneously. On the one hand there are usually a set of extremely re-usable primitives: btn, normal-text, overlay, card, etc. Then very quickly, we get higher-level components/styles that are extremely not re-usable: order-form, contact-page, etc. And other stuff in between. Applying the same structural models to all of it will cause sub-optimality at some level.

To address this, I've found that applying different models to different aspects of the css most beneficial. Basically having a mix of both utility css, and semantic css. Low-level, highly re-usable components are defined in a utility fashion so that font-sizes, colors and other things are consistent throughout the site. And complex, non-reusable high-level components that compose primitives, and other custom non-reusable css, to define the top-level components. When the need for sharing common css arises, those can be abstracted out into utility stuff, but part of the goal is to keep the utility part small so that people don't have to learn an entirely new language.

[1] https://adamwathan.me/css-utility-classes-and-separation-of-...

Re: Tailwind: A Utility-First CSS Framework

#47

Earlier quoted context omitted.

> "holy hell this is the worst thing I've ever seen" This is so true. All the classes in HTML source look so ugly and verbose when you first see it. At first I dismissed the framework and wondered how someone could think this was a good idea. I kept seeing it pop up, and the comments were always positive, so I put in a little more effort into understanding how it works. Eventually I decided to try it, and within 5 mi…

The problem I have is: what if I want to (for example) add a style or take it away from all my buttons? It's going to be a lot of manual fiddle, or is the idea that hand written sites are wrong to start with and I should be using generated code?

You can use a component. I personally design first using only tailwind utility classes. Once I reach a near-ready state I factor out the repeated code into custom components that will be easy to change in the future. That way I also don't have to wait for css to compile while I'm still making a lot of changes (I know, like 150ms right?).

.btn {

  @apply .bg-grey .rounded-sm;

}

Re: Tailwind: A Utility-First CSS Framework

#48
post #36

Earlier quoted context omitted.

Generally you’d have your button html and classes inside a component so you’re just tweaking that one component.

Then it feels like we're just back to writing normal CSS classes.

The real value for me is just being able to sit down and start. The odious first impressions of tailwind are true. But try it out. I like it because I don't waste time flipping back and forth between my document and a style sheet. I don't waste time thinking of clever class names. I don't wait a second to compile css and refresh for every small change I make (even though developer tools have been helpful in this regard, you can only make so many changes at a time). I still break it down into components later but the actual design process is more fluid.

Re: Tailwind: A Utility-First CSS Framework

#49
One of the biggest strengths of Bootstrap is that everyone uses Bootstrap. I can come to a company, use Bootstrap, and expect that new employees will also use Bootstrap or that it's already been used there! It's so common in the industry.

It also means, for front-end developers like me, that I can create a company theme on Bootstrap, and get junior developers to use it can feel comfortable with being able to implement the brand design language and not have to pixel-fiddle. Not only does this strengthen the technical skillset of my team, but it also helps keep standards high when dealing with offshore resources.

We can get them to build UI for entirely separate projects, slap our branding on it, and dramatically cut down on resource allocation, time, and effort.

So, here's the thing: this is great, but Bootstrap also has utility classes these days. If I use Tailwind, or Foundation, or Bulma, I immediate lose out on developer leverage. This is so much more powerful than moving some classes around.

Approaching all of these design concerns in a slightly different way just isn't powerful enough to outweigh the leverage Bootstrap has over everything else out there.

It's just not significantly different enough. It doesn't standout to me. In fact, how it differentiates in its introduction is a _con_ to me. No, the industry doesn't need complete UI kits, design languages vary enough that this could provide additional undesired weight, however people use buttons, drop-downs, and many other common components _all the time_.

A major competitor to Bootstrap in the arena would need to do something revolutionary.

Re: Tailwind: A Utility-First CSS Framework

#50
Please give Tailwind a try before knocking it. The syntax seems strange, but after 15 minutes you'll be in love. It doesn't work for every project, but it's a great tool to have in your arsenal. I've been following Adam and Steve on Twitter for quite some time, and these guys are total pros.
Post reply on HN