Hacker News Reader

Comment by tipiirai | Hacker News Reader

> I suspect many of the pro/anti-Tailwind arguments are no longer relevant

I feel there are two issues with Tailwind for me as a designer / design engineer.

* First, JavaScript/Tailwind engineers have hijacked the conversation on design. Instead of "utility-first," "dead code elimination," and "type-safe CSS" I focus more on desing systems. Whether to use Perfect Fifth or Perfect Fourth in typography for example.

* Second, Tailwind makes it impossible for me to participate in the actual craft. Design decisions get buried in React components with cryptic expressions like `flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)]`. This might make sense for JavaScript engineers, but blocks/makes it hard for systematic design. Instead of expressing precise mathematical relationships through CSS, we're essentially writing inline styles with better ergonomics.

View on HN

Tailwind has solved a lot of problems. And this is coming from someone who doesn't use it half the time.

Some thoughts about this topic, not necessarily in disagreement:

- Designers seldom think in the way you describe (explicit computer-readable rules, systems of design). A lot of designers are coming from crafts that are more implicit. It doesn't surprise me design business logic is not the topic of conversation.

- You need to update your tailwind classes to reflect your design business logic. Don't do "bg-gray", do "on-surface-emphasis" or whatever business logic. This is just a simple config change.

- You probably brought up modular scale as just one example, but modular type has become near myopic dogma of frontend engineers who haven't had any typesetting experience. A scale of 1.25 vs 1.5 is so in the weeds as to be useless. There are so many alternative ways to set type (e.g. take lessons from CJK typesetting) or innovate typography on the web (e.g. build your own leading-trim implementation!).

I'm a designer, so I absolutely think in terms of design systems where typography is just one part of the puzzle. There are, of course, many ways to set type — but the point was: no Tailwind engineer talks about typographic scales in the first place. Systematic thinking is absent, which is naturally built in CSS.

I'm kind of surprised why this is even relevant to you. The designers I know work in Figma. The designer and the engineer collaborate to make sure the design isn't too hard to implement, but other than that the designer shouldn't care about whether developers are using Tailwind, StyleX, Sass, vanilla, or whatever.

I hardly expect a designer to take responsibility for something as transient and idiosyncratic as "oh, but this is hard in Tailwind."

I'm (not) surprised typographic scales are non-relevant for Tailwind developers

Tailwind itself is a design system. The authors actually put together a short book explaining their point of view on design systems (without referencing Tailwind) and I found it very difficult to argue with any of their points.

Then you look at Tailwind and realize it’s almost entirely that book packaged for others to use.

https://www.refactoringui.com/

The Tailwind library names grades of colors and sizes for you, but the book is ultimately about iterating design so that you can create your own design system. From the perspective of the book, the Tailwind defaults are inadequate as a design system.

But the Tailwind configuration provides a solid structure for your own though.

just like CSS

Not really the same, although I realize it can seem that way.

If you go low level enough everything technically fits that bill, it’s just a matter of how much work you have do to put the structure in place and what the burden is for other people to learn it.

It’s akin to raw Perl vs Ruby on Rails. You can do it that way, nothing is stopping you…but there are compelling reasons not to.

That's exactly the argument I'm making about Tailwind. Inadequate as a design system. You have these bundles of rules just a thin step above CSS and there's nothing obvious about how things should look.

Maybe Tailwind is useful for bigger projects, but I tend to prefer component based class instead. The biggest DX for CSS is using the web inspector and directly modifying the DOM, then copying the adjusted values to the text editor. For a much serious project, I go with the balsamiq -> figma route to create an actual design system.

You can allow the inspector to access the filesystem and modify the files without having to copy/paste for even better DX.

Man their very playground at https://play.tailwindcss.com/ gives this unreadable crap (sorry for swearing) for the very first `div` on the first line:

    relative grid min-h-screen grid-cols-[1fr_2.5rem_auto_2.5rem_1fr] grid-rows-[1fr_1px_auto_1px_1fr] bg-white [--pattern-fg:var(--color-gray-950)]/5 dark:bg-gray-950 dark:[--pattern-fg:var(--color-white)]/10

How can anyone prefer this gobbledygook over a nice CSS class declaration with line-separated standard CSS properties ? How can one even maintain this ?

Maybe the modern generation of web developers have IQ 200 and 20/20 vision with eidetic memory and I should just put myself to pasture.

Terrible take.

Take a guess at what “dark:bg-gray-950”, “bg-white” or “min-h-screen” means. You get them from context.

Imagine if you put a little bit of effort into learning Tailwind. You’d get the more complex declarations as well.

As to why it’s better than a class declaration, a lot has been written about using atomic, composable utility classes over reams of “write-once” class declarations.

I do not disagree that there are one or two recognizable elements in that encoded line-noise. Not sure what is the "terrible take" about it - if you take a poll, most would agree that it requires far too much eye-strain to read, far too much cognitive burden to parse, decode and mentally map to concepts.

Its like deciding to code your entire your app using regexes - all in long single lines without comments.

Because your not thinking of styles practically. You don't review style declarations, you review the rendered page/component. You see with your eyes that a component has the wrong border color, and AFTER THAT you go to your component code, find the border color declaration (if any), and update it/add it. Sometimes you'll even inspect the element in browser, and find the faulty class directly, making it even easier to target in code.

The Tailwind classes are "unreadable crap", that's true, but it's not a problem because you don't "read" it, no one does. You roughly parse it and edit it.

Personally I prefer how PandaCSS does it - similar end result with atomic css at compile time but it just lets you write your styles as readable objects instead of as insane strings.

Exactly, it's not like a novel where you are trying to read the entire thing. And it's an advantage because it is easier to parse. If I'm trying to change the color on that element, I have a very good idea what controls that. As opposed to something like "card_wrapper card_wrapper--striped". That certainly looks better, but if I'm just there to change the grid, now it's a more complicated change. In Tailwind, I can just look, see "grid-cols-[1fr_2.5rem_auto_2.5rem_1fr]" and know that not only that's where to change it, but that I can also change the classname there without worrying about a regression in some other element somewhere else. Whereas with "card_wrapper card_wrapper--striped", well what controls the grid? I have to look in another file, and I also have to be concerned about every other place those classes are used. (Or I have to add new one-off classnames, at which point the complaint about long classnames holds less weight.)

No one cares what your typography ratio is if you can’t get it in front of a user quickly enough (dead code elimination), reliably enough (type safe), or cost effectively enough (i.e. if you have to pay for more developer time to implement the same work).

Tailwind is a tool for craftspeople, not artists. It democratises design by making it simpler. For folks that are really good designers, they should be happy that they can up their prices knowing that customers are paying for their expert eye, rather than just the basics again and again.

> Type safe typography ratio

Please explain how this is better than expressing typographic scales with CSS variables and calc()?

You're using a right angle bracket there like I said that. I didn't.

I would find it difficult to explain, especially given that this is exactly what Tailwind does: https://tailwindcss.com/docs/font-size.

> No one cares what your typography ratio is if you can’t get it in front of a user [...] reliably enough (type safe)

i mean it's not exactly what you said, but c'mon, that's obviously what they meant.

Ok fair enough. I was actually talking about the whole of Tailwind rather than just the typography ratios, but I can see how I could be understood in that way. My mistake. Either way, Tailwind works in exactly the way OP describes as their counter example.

Tailwind does not democratize design. Tailwind is generally 1:1 to CSS, sometimes 1:2 or 1:3. It's such a thin layer over CSS that you have to remember all the CSS. That does not make design easy or hard. You don't give people Tailwind and end up with design as beautiful as ShadCN, even though ShadCN in some perspective is just another wave of stereotypical startup design. The ability to go from blank button to beautiful Tailwind button is all on the author, not the fact that you're writing in a new lightweight inline syntax.

When I read the Tailwind book, my takeaway was their design philosophy was about the speed of iteration and how that interacts with designs whose parameters are too interdependent. Tailwind follows that philosophy by encouraging ad-hoc repeated edits over DRY. In that sense StyleX also fits the Tailwind philosophy very well even though StyleX is an even thinner layer over CSS.

I don’t really agree. You have curated colour palettes, so if you want a red, you’ve got red-50 to red-950, rather than an entire RGB colour space.

Similarly for font sizes, you don’t have to decide on a pixel size, just whether it’s small, large, extra large, etc. Border radii. Border widths. Padding.

There are lots of “sensible” defaults so you don’t have to pick even the units (should I use px or pt or em or rem or vw or ch or…) before we even talk about the numbers associated with those units.

You should really not do it like that,

--corporate-main-primary, secondary etc

Then map that to red-50 if you really want to.

but a design lives in cmyk/ral/rgb/hex not red-650

The go

--action-button-cta-hover etc that could map to corp primary or some other stuff

The Reactoring UI book would find whatever structure of defaults given to you as very inadequate for a design system. The book is about an iteration process for creating your own design system. The Tailwind library happens to empower that design process.

But by default there's basically no opinion on what even a button should look like or how colors should be used on your website. You have to create your own abstraction such as "brand-color" and "brand-primary". You have to create your own design system, as there is no Tailwind default button or anything.

If you talk about a default Tailwind look people might be confused and think of ShadCN.

Just because you can build great things with Tailwind doesn’t mean it’s not democratising design. In the same way as putting frets on a guitar helps amateur players make better music without stopping great players doing their thing, Tailwind is the “frets” on CSS that make sure your hands play the right notes. You can still get it wrong, and you can do inspired or uninspiring design with Tailwind, the same as any tool.

Reply on news.ycombinator.com