Why Tailwind CSS Won • Hacker News Board

Re: Why Tailwind CSS Won

#461

Post by greenie_beans » Wed, Aug 16, 2023, 3:33 PM UTC

blitz_skull wrote: post #267

keyle wrote: post #140

Gray beard's 5c: Tailwind is a farce and a catastrophe. It's as modern as the style parameter is, and it's as reusable as a moving a dirt pile from one corner to the next. You're not learning anything valuable by learning Tailwind. Learn CSS, that will stick with you for the next 20 years. It amuses me when a library is implemented 'with tailwind', which means it's totally useless to the people _not using tailwind_,…

Cool hot-take but it’s not true. You’re literally learning CSS when you learn tailwind. And no one (good) picks up a tool solely because it’s shiny, they pick it up because they find it has utility, which evidently LOTS of people do. And if you don’t think it’s reusable then you at least need to bring an argument for why that’s so because the docs, personal anecdote, and the opinion of LOTS of people is completely op…

yeah i'm only able to use tailwind because i know the fundamentals of CSS

Re: Why Tailwind CSS Won

#462

Post by afiori » Wed, Aug 16, 2023, 3:52 PM UTC

nottorp wrote: post #397

afiori wrote: post #372

Earlier quoted context omitted.

Do you know how Tailwind works? What you say is generally true, but I don't really see how it applies to TW...

No of course I don't. And due to javascript's reputation, I assumed. Because what I said IS generally true for the js bubble. The sad part is i don't even feel guilty for assuming, because this area of programming has a well deserved reputation. Even if this thing doesn't use javascript, can you guarantee the generated CSS doesn't put the browser's layout engine in an infinite loop or something? Especially without kn…

> can you guarantee the generated CSS doesn't put the browser's layout engine in an infinite loop or something?

the way TW aproximatively works is to collect a set of used class names from your code (e.g. flex, min-h-screen, bg-[url(/img/grid.svg)], absolute, etc.) and produce the CSS for those classes.

For the random 5 classes above it would produce:

    .absolute{
      position: absolute
    }

    .flex{
      display: flex
    }

    .min-h-screen{
      min-height: 100vh
    }

    .bg-\[url\(\/img\/grid\.svg\)\]{
      background-image: url(/img/grid.svg)
    }

By default TW also includes a CSS reset preamble and defines internal variables.

Sometimes the generated css contains complex selectors but as far as I know it is not a common occurrence

    .space-y-4 > :not([hidden]) ~ :not([hidden]){
      --tw-space-y-reverse: 0;
      margin-top: calc(1rem * calc(1 - var(--tw-space-y-reverse)));
      margin-bottom: calc(1rem * var(--tw-space-y-reverse))
    }

In other cases more css variables (custom properties defined in the preamble) are used

    .-translate-y-1\/2{
      --tw-translate-y: -50%;
      transform: translate(var(--tw-translate-x), var(--tw-translate-y)) rotate(var(--tw-rotate)) skewX(var(--tw-skew-x)) skewY(var(--tw-skew-y)) scaleX(var(--tw-scale-x)) scaleY(var(--tw-scale-y))
    }
    .shadow-xl{
      --tw-shadow: 0 20px 25px -5px rgb(0 0 0 / 0.1), 0 8px 10px -6px rgb(0 0 0 / 0.1);
      --tw-shadow-colored: 0 20px 25px -5px var(--tw-shadow-color), 0 8px 10px -6px var(--tw-shadow-color);
      box-shadow: var(--tw-ring-offset-shadow, 0 0 #0000), var(--tw-ring-shadow, 0 0 #0000), var(--tw-shadow)
    }

I believe that CSS performance is mostly dominated by size in bytes of the stylesheet, number of properties, complexity of selectors, and frequency of updates. I suspect that TW improves most of these metrics in exchange of bigger html class attributes.

https://play.tailwindcss.com/

Re: Why Tailwind CSS Won

#463

Post by spion » Wed, Aug 16, 2023, 3:55 PM UTC

epolanski wrote: post #281

spion wrote: post #234

Earlier quoted context omitted.

One of the things that tailwind achieves is let you ship style in a way that is encapsulated within components and works reliably across any framework (including server-side rendering frameworks, react, svelte etc).

That's not unique to tailwind.

What other approach gives you that?

Re: Why Tailwind CSS Won

#464

Post by sibit » Wed, Aug 16, 2023, 3:56 PM UTC

nkohari wrote: post #420

sibit wrote: post #274

Earlier quoted context omitted.

It's the minor inconsistencies that prevented me from using Tailwind on any serious projects. I've never been able to get past their choice to use text-{color} instead of font-{color}.

That isn't an inconsistency, it's an intentional choice. The color of the text is an aspect of the text, not of the font. The corresponding property in CSS is color, not font-color.

> The corresponding property in CSS is color, not font-color.

So why not color-{color}-{shade}?

Re: Why Tailwind CSS Won

#465

Post by game_the0ry » Wed, Aug 16, 2023, 3:58 PM UTC

I see there is a lot of fair critiques about tailwind, many I agree with.

But as someone who works on UIs built with react, it's nice to not have then need to leave my JSX components - html, js, and css (via tailwind) are all nicely colocated. Especially nice with the vscode extension that shows the css rules of the underlying css decleration.

I agree that fundamentals trump all, but tailwind is a nice css abstraction that hits my use case well.

Re: Why Tailwind CSS Won

#466

Post by stickfigure » Wed, Aug 16, 2023, 3:58 PM UTC

cdelsolar wrote: post #415

keyle wrote: post #140

Gray beard's 5c: Tailwind is a farce and a catastrophe. It's as modern as the style parameter is, and it's as reusable as a moving a dirt pile from one corner to the next. You're not learning anything valuable by learning Tailwind. Learn CSS, that will stick with you for the next 20 years. It amuses me when a library is implemented 'with tailwind', which means it's totally useless to the people _not using tailwind_,…

Even grayer beard's 5c (well, I'm still under 40, but still): You could not pay me enough to learn CSS. Every time I have to debug CSS there go many valuable hours of my life. With an insane amount of trial and error and judicious use of Chrome's dev tools I can usually hack some garbage together, until the next time I have to figure out how to remove the background of a button. In the literal 90s I was building full…

I'm 50 and spent most of the 90s building Windows GUI apps. I think you misremember it. As a general rule dialogs (especially the ones built with dialog builders) were static with fixed pixels sizes; double the screen resolution and the dialogs were half-size. Layouts were extremely static; even Java AWT's primitive flow layouts were almost revolutionary by comparison to what was available in MFC et al.

Modern web design is a mess, yes, but it's vastly more sophisticated than what was available in the 90s and I would not choose to go back.

Re: Why Tailwind CSS Won

#467

Post by nkohari » Wed, Aug 16, 2023, 4:05 PM UTC

sibit wrote: post #464

nkohari wrote: post #420

Earlier quoted context omitted.

That isn't an inconsistency, it's an intentional choice. The color of the text is an aspect of the text, not of the font. The corresponding property in CSS is color, not font-color.

> The corresponding property in CSS is color, not font-color. So why not color-{color}-{shade}?

Because text-{color}-{shade} is more descriptive of what the color affects. Again color is not an aspect of the font (which is the typeface plus styling like weight, size, etc.) so naming it font-{color}-{shade} would be technically incorrect. (You can argue that ignoring this technicality would result in a cleaner API, but the comment I was replying to was suggesting it was a mistake, which it isn't.)

Re: Why Tailwind CSS Won

#468

Post by haswell » Wed, Aug 16, 2023, 4:13 PM UTC

marcosdumay wrote: post #450

naasking wrote: post #416

Earlier quoted context omitted.

> It's just that this switching happens when working on the data, instead of on the style. You mean you have to think about how the data you're styling looks while actually looking at the data you're styling? Sounds terrible. /s

You have to think about how the data looks like while you are editing the data. But I do think my comment was clear.

Your comment was really not clear to me at all, so I think I’m missing something. Where is the context switch here?

To me, context switching is about changing what I’m currently looking at on the screen and going somewhere else to define something in some other context: a different source file, a different system, a config file, etc.

If you’re continually leaving the context of the HTML that will render your data in order to manipulate that data, that sounds like a different problem that can easily be solved by using mock data or by hooking up to a real data source. This is true regardless of CSS approach.

Re: Why Tailwind CSS Won

#469

Post by jonwinstanley » Wed, Aug 16, 2023, 4:18 PM UTC

TOGoS wrote: post #455

3cats-in-a-coat wrote: post #401

Earlier quoted context omitted.

First, the site uses some weasel language to speak about how much they're "focused on performance" in such a way as you think Tailwind is literally faster than doing normal CSS. It's not. It's a heavy approach and while you can always find edge cases to the contrary, in general it leads to pages that add lag and load to people's devices. If you have a very simple page this doesn't matter, but as your site/business gr…

I would donate more upvotes to this multi-part tirade if I could. I haven't used Tailwind, or any other CSS framework, because I have never understood why I would want to, having attended a talk about a similar system back in the day where styles were turned into weirdly specific CSS classes, as if they were trying to reinvent font tags. The way you've described it is pretty much what I would expect from such a thing…

Hahaha - I wonder if Tailwind is starting to take over from frameworks v no-framework as the best way to start a huge fiery debate on HN!

Re: Why Tailwind CSS Won

#470

Post by haswell » Wed, Aug 16, 2023, 4:21 PM UTC

emmacharp wrote: post #269

jonwinstanley wrote: post #256

Earlier quoted context omitted.

I suppose one of the good things that Tailwind does is it stops you having to name every element and all the different variations. So you don't end up with wrapper, container, container-thin, image-wrapper etc etc.

But you really don't have to do that. Naming components only (as you already are) really is sufficient. And yes, specificity and flexibility can easily be managed/included with CSS, particularly now, with all the new widely supported features/selectors. These solutions to an old "problem" are lighter, simpler and easier to maintain in the long run. If you're curious, I'll be pleased to give you more concrete examples…

Most of my HTML/CSS skills were formed when these things did not have good built-in solutions.

As someone who just wants to hack together a responsive blog that looks nice, the things that are now “simpler and easier in the long run” have not been easy or obvious to come by when looking for resources, and while I’d love a deep knowledge of CSS, the investment in time doesn’t make sense given my use case. This is why I gravitated to Tailwind - learn the conventions of the utility classes (only took a few minutes) and the rest mostly just works.

I’d love something like http://vanilla-js.com/ but for modern CSS. Something that paints a crystal clear picture about what can be done, and how to do it without bringing in $framework.