[superice]

Starting from 'what looks good' is putting the cart before the horse. Making a UI usable and well laid out first is key. Practical UI and Refactoring UI are great resources, as long as you read them through a lens of 'what works well?' instead of 'what looks pretty?'. The author is absolutely right in that alignment and consistency are important, but that should really be your starting point.

Building a good user interface is fundamentally an engineering challenge. I see roughly two camps in building UIs, one designing a pretty picture and then tweaking the CSS until it looks like the picture, the other treating the CSS as rules of how the UI should behave. A simple example would be using display: flex; gap: 32px; on a parent of two elements instead of margin-right: 32px; on the left-most element. While the end result is identical, specifying the gap on the parent is better, because it puts the responsibility for spacing in the correct place. This also goes for the way you define CSS classes and rules, if two values are linked, like the height of your buttons and the height of your input fields, then try and capture that in a single rule, or extract it out to a variable.

A lot of building good UIs becomes much easier once you adopt the engineering approach. Consistency is almost built-in at that point, and that automatically makes your UIs better and easier to understand. It keeps your CSS more maintainable too.

While I'm sure there are ways to achieve this with Tailwind, generally I tend to see developers do the exact opposite when they use tools like that: just define everything with atomic classes inline, and forget all about the relations of styling rules to eachother. Tailwind has some great concepts, like defining a limited set of values to choose from, but be careful to keep the engineering, rules based way of building UIs.

There are so many times we've gone a direction in our products only to figure out that while we could make the page look pretty, it never would work well. It always ends up being some version of 'if we go direction X, then features Y and Z will have to be shoe-horned in and it'll look ugly'. When you get that feeling, take a step back, come up with some different approaches, and go with a better one.

The "make it pretty"-step should really be the last thing you do. If you design your UI with heavily visually simplified components and in black and white, it should still work and feel right. Make it work right, and the pretty will come.

[dzungfz]

> The "make it pretty"-step should really be the last thing you do. If you design your UI with heavily visually simplified components and in black and white, it should still work and feel right. Make it work right, and the pretty will come.

Totally agree. I’ve fallen into the trap of chasing “cool” or fancy visuals first, but the most beautiful UI is the one that actually solves the user’s problem. A slick-looking interface that doesn’t work well isn’t really beautiful at all.

[tkzed49]

I don't understand when people see Tailwind as anything other than a syntax for CSS.

> forget all about the relations of styling rules to eachother

This is a hot take, but the more cascading your styles are, the harder they are to read and debug. I've never been upset to find classes that just correspond 1:1 with DOM elements. And that's what Tailwind is doing.

[superice]

I'm not necessarily arguing in favor of deep cascading, but I don't see how something like this:

.form-element, .button { height: 32px; }

Is something that can be easily achieved with Tailwind without either using @apply all over the place, effectively now doing regular old CSS but with Tailwind syntax, or by using JS/TS variables extensively making the styling pretty hard to read. Either way, I'm not saying Tailwind makes it impossible, but it sure doesn't make it easier. And while Tailwind has a bunch of benefits, especially where it becomes a design system rather than a syntax for CSS, you can achieve ~90% of that by just defining a bunch of color and size variables at the root of your CSS and using that.

I don't mind Tailwind too much for 1:1 mapping with DOM elements, but I also don't really see why inline styles for that case would be bad.

[balamatom]

>And that's what Tailwind is doing.

What DOM element does "shrink-0 w-6 h-6 mr-2 -ml-1" correspond to?

[WA]

Tailwind's default sizes add constraints, which makes Tailwind a bit of a design system. Also, Tailwind's default colors are just very pleasant to work with. Even on projects where I don't use Tailwind, I look up the color table in the docs.

[CrulesAll]

"Starting from 'what looks good' is putting the cart before the horse. Making a UI usable and well laid out first is key." This is first principles yet is so often ignored.