Hacker News Reader

Comment by kolektiv | Hacker News Reader

Ok, so I could mark everything as "brand-dark" and then change the definition of that in the CSS? Mmm. Ok. How about layout and sizing? A lot of that looks a lot more defined - I'll pick a random example from their own homepage then: "border-b border-gray-200 py-6 flex items-center justify-between mb-16 sm:mb-20 -mx-4 px-4 sm:mx-0 sm:px-0" - if I wanted to change my approach to centring, justification, and sizing, it still seems like a lot of search and replace...

(I think I understand that the approach is that I'd then change what those definitions mean centrally - but that won't help me if I decide that two properties which are currently different should be the same, or vice versa).

View on HN

Layout tends to be a property of a particular component, and semantic classes don't work well there either.

In a complicated codebase with multiple devs, the number of times you could confidently make a "one-place-CSS-change" to a semantic layout class is very small. It's likely that in one place or another, some dev made an assumption about your `sub-container` class or whatever, which causes your change to break their layout.

Most large codebases thus end up with a TON of very specific class names (often used in one place), so the dev can be confident in their layout; this is the biggest contributor to unmaintainability that I've seen in large applications.

If everyone is forced to use e.g. d-flex justify-content-center ..... it hugely improves readability as any developer can quickly look at any layout and see what is going on without building a mental index of semantic class names that the original dev chose.

but my Cards are design components, they don't have semantic classes. How is ctrl+f "border-b border-gray-200 py-6 flex items-center justify-between mb-16 sm:mb-20 -mx-4 px-4 sm:mx-0 sm:px-0" better than changing .myCard__title{}?

I guess it depends on the project, but I can't recall one time I've had to do a CTRL F like you've mentioned.

Of course if you have a very simple page with just some cards, a couple page layouts, that is one thing. Probably can get by with just a myCard class that works everywhere on the site.

But in most projects, as the number of custom components grows, nobody wants to go back and touch (break?) old CSS, so they end up just writing a bunch of fresh stuff for this new feature and throwing it on the pile.

This problem happens often, while the refactor-in-one-place case happens very little.

I was going to say the opposite. Search-and-replace would never work on a high-volume site with a lot of components. Replace ".font-bold" and you just affected anything that was bold across the entire site.

I could see a use for this in JSX though.

Then you extract components. https://tailwindcss.com/docs/extracting-components

Instead of repeating "d-flex justify-content-center..." everywhere is it possible to define that once and inherit those properties in Tailwind?

Definitely, you can still add custom classes where it is the best solution, such as a reusable layout.

EDIT: Instead of custom CSS classes, Tailwind recommends extracting components like the other commenter pointed out. https://tailwindcss.com/docs/extracting-components

Then you extract components. https://tailwindcss.com/docs/extracting-components

> Create a template partial or JavaScript component

The parent comment was specifically about not using components.

But you use your Bootstrap/Tailwind utility classes in JSX. Now your styling is tightly-coupled to your component again. Isn't that just CSS-in-JS with more steps and less power?

Reply on news.ycombinator.com