> about a month and a half ago
> unmaintainable soup were unfounded
I see this a lot, but rarely with a qualification. How did it quell your fears about unmaintainability? What about tailwind makes it maintainable?
Tailwind is similar: instead of extracting styles out to a separated styled component or even a separate .scss file, you collocate them with the rest of your layout. When I read code using Tailwind it's easy for me to "see" how things will look in a similar way that I can "see" how a React component will function at run time.
More concretely, I think these three things were important for me:
1. There's a really solid design system underpinning the Tailwind utility classes. With styled-components you start from nothing, and with off-the-shelf component libraries (e.g. MUI) you get a design system that isn't quite as well thought out. Tailwind's classes just work together really well out of the box because the defaults are so sensible. I'm not a designer, so this is a really big win for me.
2. Components help prevent class soup. I suspect I wouldn't enjoy Tailwind quite so much if I were writing plain HTML, but for things which _do_ need to be reusable like button styles I'm still writing code that looks like `<Button>...</Button>`. Nothing really changes here from styled-components -> Tailwind other than how the styles are written; they're equally maintainable.
3. One-off snowflake UIs are really easy to implement, because you can just write your classes right then and there. I've never worked on a nontrivial web application where _everything_ fits cleanly into the design system, and going through the ceremony of creating a styled component just to add a little bit of additional spacing is a pain. It also sucks for maintainability because a name like "Spacer" doesn't tell me anything about the styles, so I need to context switch and jump to the definition. In contrast, seeing "mx-2" instantly tells me what's happening.
I do think Tailwind's something that benefits from first-hand experience, though.
edit: syntax
- styling is scoped to your components. You won't break your UI trying to refactor rules & selectors
- by default you don't need to invent class names. The components provide enough context
- it forces you to make a selection of colors an spacing, leading to a more coherent style.
- it is easier to understand than a lot of other css frameworks. It is just a "basic" rule generator with some QoL like automatically pruning the rules you are not using in the production code.
1. It increases mental overhead. It is not possible to tell whether a component contains pure CSS styles or adds some functionality, unless you open it and read its code (in that point, it has lost all of its benefit for me). With CSS classes or even HTML style attribute, this distinction is immediately obvious: style vs. function.
2. It clutters the codebase. You'd find all sort of little components sprinkled everywhere.
Both of the above critics could be addressed by implementing a convention, however. For example limiting the use of styled-components to a specific package. The second issue is mostly programmers' fault, not styled-components. However, with CSS I don't have any of these problems to begin with.