JLehtinen · HackerTrans

I find it a little bit backwards that semantic CSS class names should be invented by the developers. If there's a working and well-organised design system in place, then there should be little need to come up with arbitrary names for things. At the very least the designer(s) should be consulted, because they have experience and insight into which elements have common styling with each other and how they are placed in context. In general, I think Tailwind's popularity has a lot to do with developers typically not being designers.

JLehtinen

2 anni fadiscuss

Several reasons to use "primary" class for buttons – `button` is just one of the elements that gets used with button styling, but there might also be `a`, `div` or `input` tags that look like buttons, depending on the use (or source).

JLehtinen

2 anni fadiscuss

They are (encapsulated in reusable components). But when the project grows big, Tailwind's shortcomings become apparent, the biggest ones being the loss of context (cascading) – and of course the lack of separation of concerns, when the concerned parties are also separate (developers and designers).

When building a design system, there are a bunch of default styles, and then there are variations based on context. To put it in a real world example, imagine a newspaper heading style that varies depending on where the heading appears. Front page headings are bigger, sports pages might use a different style, and so on. Same with buttons, cards, tabs, what have you.

This isn't impossible to build with Tailwind by adding, say, react logic, but it becomes a mess quickly. If you have a well-built design system, class naming shouldn't be that hard to figure out and communicate to developers. But deciding on a coding logic to account for these context changes and sticking to it seems not as easy, especially when developers come and go.

JLehtinen

2 anni fadiscuss

I’ve worked on some large projects including refactors with Tailwind and my view is opposite. I can see how Tailwind would work on small projects, or ones where the designer never touches the styling inside the code. But on the other hand, avoiding naming because it’s hard isn’t how I approach organising design, and it doesn’t sound like a good approach to coding either. But I can see how there may be a need to bypass it in projects where there is no designer, or a design system.

JLehtinen

2 anni fadiscuss

Being a designer who does his work inside code, Tailwind is a nightmare. I hand off my design files, the developers do their thing. But then, maybe I want to tweak things after a review, or the design system changes, so I have to do a sweeping change to those buttons. Now I need to touch dozens of jsx/tsx files around the platform and make humongous pull requests, and the result is often dozens of merge conflicts. If I only touched CSS/SASS files, there might not even always be a need to have the files reviewed.

Another problem is readability. When things aren’t getting named, the files are often unreadable at first glance. And that’s what they are to external services like Pendo, which rely on classes to tie their thing into the UI. Which are now susceptible to change on a very regular basis, because when you change Tailwind styles “that only changes that particular instance”, or so the story goes.

comments