A lot of people I respect really like Tailwind, but I just don’t get it. Seems like you end up with walls of classes because you don’t name your compositions, and thus your design system doesn’t actually live anywhere. If you have a standard box in your design system with a certain padding, spacing, font size, and so on, are you really going to write out all its constituent properties every time you use it? How do you manage that effectively?
As an alternative, use a scss mixin (or even just a class) called standard-box and then use it everywhere. Do that for all the major parts of your design and you’ve created a language with which to build individual chunks of UI. Modifying the design system itself isn’t free but it’s a lot easier than mapping the change to every use of every tailwind class.
> A lot of people I respect really like Tailwind, but I just don’t get it.
I think I get it. For years there have been lots of popular CSS authoring conventions for JavaScript apps that are clever but complicated, fragile, and have a lot of churn. Most of these either have large JavaScript runtimes that generate and inject styles on the fly as components render, or deep integration into the JavaScript build system like Webpack/Babel/etc. plugins, or both.
I believe that there was intense fatigue from supporting these systems, keeping up with the newest versions and trends in the high-churn JavaScript ecosystem, etc. Tailwind essentially offers a ridiculously simple way out of this fatigue. You just say screw it, let's just author all our JS component styles using string literals that from JavaScript's perspective are just totally arbitrary HTML classes. No more importing things, or using plugins that transform the AST of our JS source code, or extracting chunks during SSR, etc. We just run this totally separate Tailwind compiler that looks for string literals that seem like Tailwind utility classes and generates a stylesheet that we just import in our HTML.
Tailwind is pretty great on its own as a utility CSS framework. There's a lot of thought put into the "API" of their utility classes, and because it's so popular there is a ton of support for almost any use case you'll come across. But at the end of the day, I think the reason for its ubiquity (particularly among respected veterans and "influencers" in the frontend community) is that is offers a way out of the "JavaScript tooling rat race" that was causing so much fatigue.
You manage this complexity the same way you manage the complexity of repeated code nearly anywhere else: you encapsulate. If you have a standard box (div + styles) that you use everywhere, abstract it in whatever way you're writing your application allows. For example, a component in React.
Or...a CSS class? I think the point is that CSS already has the means for abstraction built right in. Using an application framework in order to abstract a list of styles adds unnecessary complexity that compounds upon itself.
Somebody writes a React component to abstract a button and its standard styles, and all seems simple enough. Then we need marketing styled buttons, and buttons that are anchor elements, and ones that are small and large, and inverted and with and without shadows because the design people insist, with icons, block width, pills, etc, etc. And you end up with a monstrosity component with all sorts of bespoke interface that everyone has to learn, when some cascading classes and plain HTML would have entirely sufficed.
That seems to be a straw man its never just plain html and CSS. Even if it were, what you describe just devolves into dozens of similar or slightly different (many times by mistake) classes that all need to be maintained.
I would much rather dig into a component that has been built to be flexible for all of those needs to keep it up to date, restyle of add new behaviors and designs requirements vs going through hundreds of html files looking for all of the classes that were created to do those variations you list above (including effectively duplicate (or worse yet cascaded with different behaviors to accommodate the different html construct they were placed on when created).
I really did dislike tailwind from first learning about it, but using it has turned me on it 100%.
I think the usual solution here is just to make your standard box a component, as opposed to using a div with a class. Then if your design system changes, you just change the wall of tailwind classes in that single component file.
I'm very sceptical of class-based CSS solutions because I had "do it semantically" drilled into me when learning it.
However I think I'm starting to come around because it finally clicked that modern web programming already abstracts styles on another level, as components.
So instead of repeating yourself, you create something like a StandardBox component and it brings all of its styles.
It still doesn't look or feel very elegant to me, but this seems to be the compromise most web developers are willing to make. Changing the theme seems to be mostly done through variables.
I use view components (ViewComponent gem) aggressively. Instead of having a .standard-box class, I have a StandardBox view component that owns all of its own utility classes.
On the rare occasions where I need to duplicate groups of Tailwind classes, I’ll extract those into ‘semantic’ CSS classes using @apply.
As an alternative, use a scss mixin (or even just a class) called standard-box and then use it everywhere. Do that for all the major parts of your design and you’ve created a language with which to build individual chunks of UI. Modifying the design system itself isn’t free but it’s a lot easier than mapping the change to every use of every tailwind class.