Live data from Hacker News

Tailwind CSS v3.0

tailwindcss.com

371–380 of 448 posts

Re: Tailwind CSS v3.0

#371

Every time Tailwind does something great and gets posted here, the conversation devolves into the same arguments: “I don’t get it. It’s just inline styles.” What is it about CSS that gets people so offended and opinionated? If it were a new JS framework, few people would be saying “I just don’t get XYZ. Use React”. Is it because Tailwind is so drastically different and breaks people’s core ideas about separation of c…

For me, the situation is: I gave tailwind a try. I hated it. I spent a lot of effort of ripping every last tailwind class out of my project. And yet, a lot of people swear by it and think its great. This really confuses me, and I'd kind of like to understand: how can other people like this thing that I think is terrible?

> how can other people like this thing that I think is terrible

Cause it works for them? You cannot be the arbiter of what other people like or don't

I hate CSS and I find the TW classes being right there with the HTML more helpful than class-hunting through a bunch of CSS files. React solves that somewhat with styled components now. I like having design guidelines set loosely about things rather than writing reams of CSS myself. I like having media queries defined right there in the HTML. I LOVE the flexibility it offers me and how quickly I can iterate through concepts and styles

Re: Tailwind CSS v3.0

#372

Earlier quoted context omitted.

I often have trouble writing CSS. Here is how I approached this challenge. https://jsfiddle.net/mwabc719/ Anyone have good advice on a better way?

> without modifying the HTML > Here is how I approached this challenge ...but you modified the HTML?

> ...but you modified the HTML?

The original challenge includes questions that apply only if the resolution involves HTML modifications, which (contrary to the earlier text viewed in isolation) indicates that such modifications are not invalid in response to the challenge.

Re: Tailwind CSS v3.0

#373

Earlier quoted context omitted.

I use Tailwind utility classes extensively to create reusable components in a Rails app using GitHub's ViewComponent gem ( https://viewcomponent.org ) Occasionally, I'll use @apply directives to DRY up something that isn't easy to encapsulate at the component level, but 95% of the time, I can easily get by with utility classes. I try to avoid using hyperbolic-sounding language like 'revolutionized,' but Tailwind + Vi…

Thanks mate! I've been considering this path and may give it a go. Although, I'm still a bit nervous spitting utility classes all around. That sounds almost like inline CSS and almost unmaintainable.

The usage of utility classes only become an issue if you have unnecessary duplication of components. Say, two buttons that should be the same but are implemented in different places.

IMO one of the interesting parts of functional CSS is that we can apply the same tactics we use for organising code to organising the styling.

Also, with separated CSS, and especially with semantic CSS, there is often a fair amount of duplication that happens in the CSS code itself, which we programmers tend to be very forgiving of. Giving Tailwind more scrutiny than we do for our CSS ends up making our code more consistent, less duplicated and better in general.

Re: Tailwind CSS v3.0

#374
I am the one who always has had issues with TailwindCSS. But now I know why. It's not because it's polluting HTML. It's because I am not one of those, who can whip up some cute buttons on the fly. I have no idea how to apply padding, chose fonts, colors or combine shadows. I'm better off with CSS frameworks which provide me with these things out of the box. TailwindCSS ir just a method for rapid designing, which I am totally incapable of.

Re: Tailwind CSS v3.0

#375

Earlier quoted context omitted.

>This works okay in extremely componentized web apps. It's a nightmare if your UI isn't highly componentized. I've seen projects where you make a button by copy pasting this ~80 character string of tailwind classes all over the place, and then changing the color names if you need to. Good luck fixing that when the designer decides that we don't want any buttons to have rounded corners anymore. That app is done wrong.…

Yes, there is a right way to do it. But in the code I've seen in the wild, people are often not doing it right and those 80 char strings of utility classes are on the low side compared to some of what I've seen. I'm skeptical of Tailwind not for its own sake but because a lot of (most?) shops do not have the discipline to use it effectively. And what you are arguing here is basically a no true Scotsman defense.

I wonder if there's an ESLint rule out there to limit how many tailwind classes you throw onto one thing...

Re: Tailwind CSS v3.0

#376

Earlier quoted context omitted.

> if you litter your code with styles such as "font-semibold" and "font-sans", isn't that just going to mean you have a million places to change If, instead, you litter your code with my-brilliant-semantic-class you create a different kind of problem. Requirements change and my-brilliant-semantic-class won't be sufficient. Now the choice is; alter my-brilliant-semantic-class and suffer all of the unintended side effe…

One underrated problem with semantic naming and classic CSS is having to repeatedly do one of the two hardest problems in computing, that is naming things, 5 times per minute while you're trying to be creative. You constantly have to context switch between "design/creativity" and "logic/pragmatism" mental modes. It's awful, exhausting and doesn't enable any state of flow. The productivity loss is enormous.

I think you're discounting the value of naming though.

You don't refer to bananas as "the curved sweet yellow food that grows on trees", you simply refer to a banana as a banana.

Sure, for one off items it might not make sense to name it but when you create design patterns then it's incredibly useful to be able to name things.

Yes it may be hard and require you to think, but just because that is so does not make it bad necessarily.

Re: Tailwind CSS v3.0

#377
post #247
post #239

Earlier quoted context omitted.

Looks like Tailwind has an answer to this: @apply. https://tailwindcss.com/docs/reusing-styles I am going to give it a try. The argument against using it is that it defeats the purpose of Tailwind, but I think its useful to start by spraying classes until things work and then moving those classes into e.g. btn-primary once the styles become stable and need universality.

Yes, @apply exists, but is generally discouraged (and the rationales are given right on that page) > If you start using @apply for everything, you are basically just writing CSS again and throwing away all of the workflow and maintainability advantages Tailwind gives you Approaching it with moderation is probably worth trying though

It's the same as any DRY or optimised code: taking time and effort to make things overly DRY or optimised up front is a waste, building stuff out and then refactoring when you realise it's going to be repeated is a better workflow. With tailwind, that's simple because you take your string of class names, slap an @apply on it, and then use the new classname instead. No, it's not significantly different from just writing CSS then, but it's the workflow that's changed that reduces the friction between prototyping and then refactoring into a reusable design that makes Tailwind nice to work with in my experience (and I'm using it for a large-scale commercial project, not a landing page or static site).

Re: Tailwind CSS v3.0

#379

Earlier quoted context omitted.

No, we don't want all of the buttons to look identical. Some are big and some are small; some are bold and primary and some are muted and secondary; some have icons; some have shadows; some are disabled, etc, etc. It's easy to make them identical. The challenge is to be as flexible as necessary in a mature application, while minimizing verbosity and complexity. In my experience Tailwind hurts more than it helps here.…

How would you have done it without TailWind? You'd still have to create classes for each of them in plain css anyway, except it would probably be in a different .css file. The inherent complexity pertaining to your app is not taken away, it just moved the places.

My point is that plain CSS is already good at this. So then you don't need to make more components with their own interface to learn.

    Edit

    .btn {
      ...default button styles
    }

    .btn.large {
      font-size: larger;
    }

    .btn.shadow {
      box-shadow: 0 0 8px #0004;
    }

Re: Tailwind CSS v3.0

#380

I tried Tailwind (and a similar project Windi) on a few projects now and have some findings. Tailwind aggressively speeds up development time of components by allowing me to stay in the same cobtext when styling things. The brevity of class names also dramatically shortens the time spent writing styles. While working on the projects I'd setup with Tailwind, I felt far more productive. However, those were new projects…

I found exactly the same with my brief experience with Tailwind. Great fun to write, couldn't make head nor tail of it when I came back a few weeks later. Perhaps this changes if you use Tailwind day in day out though!

I've stuck with styled-components for now, though I confess that I've started to wonder if the the verbosity of creating a (styled) component for everything, passing props, etc. is a bit excessive since trying Tailwind.

Post reply on HN