Comment by vitamark
7 days ago
Tailwind, IMHO, doesn't bring any real value to the developer or the codebase.
It's just a weird way to write CSS right in the classes. We have a tool for that, it's called "writing CSS", and it actually has classes that allow sharing style choices across various components (which somehow is marketed as feature of TW)
In other words, I don't see how Tailwind is just "I want to write my CSS in obscure way in the wrong place".
Code locality has some advantages and some disadvantages.
A “perfect” website has things cleanly separated out between style, logic, and DOM, but that does cause cases where you might have to edit three files every time you change a single widget of your website. Neglecting to do that can leave dead or incorrect code just because the issues do not inherently present themselves to you.
Yes, a perfectly principled programmer would do it right… but have you worked with other people before? They’re not necessarily very reliable.
I'd argue that it's impossible to have locality in all aspects. If your style, logic, and DOM are separated almost certainly you have a separation in domain - you're going to have styles, logic, and DOM concerned with "widgets" in your product and if they're separated by whether they are style or logic that means they can't be correlated by their "widgetness".
Really the decision comes down to whether it's better to separate based on style/logic/dom or on the business domain, and I think at least for web apps, separation by domain wins out in most cases.
There are a couple of things:
1. Locality of behavior - the classes are the description of the style once you know tailwind, and they live where the thing they're styling is. I can look at a template and know pretty well how it is going to look without having to go lookup a sites personal bespoke CSS and match what's written there to the markup.
2. It's the same classes as you move from project to project. I have tons of small one-off apps I maintain, all using tailwind and I don't have to figure out the custom CSS classes and their meanings. It is a knowledge set that reduces friction between projects and I really need things that reduce cognitive load like that.
3. No dead CSS. There are tools to help with this in regular CSS but I just don't have to think about it with tailwind and that's nice. I work on my templates and the CSS is updated and minifed on the fly without extra steps (or unnecessary CSS).
4. Easy to build a personal component library that doesn't also require relevant CSS to be bundles with it. For me this one is pretty great. Thanks to template engines (for me it's Django's, but Jinja or others are grand too) I have a simple place to pull components (really just template partials) and widgets I've made and they just work because the underlying classes are the same. There are some exceptions around color schemes and the like but now all my little components take a colour scheme arg and voila, no proballo.
I think the key here is that a description of the visual is embedded in the markup. That lets the actual mark-up delivered to the front-end describe pretty much the whole kit. With server-side rendering ( I use HTMX ) I can even write unittests that responses contain expected markup, including CSS classes (I built a few helper assertions that all of my test suites use) which gives me some interesting checks.
I really ultimately don't think there is one correct way to do things. The things I value may be utterly irrelevant to another developer.
I see the point, but really this is solved better by having a solid foundation of UI components (might be an existing UI-kit or own thing, a piece of CSS anyway), and then you can use the same-ish classes over many sites.
What I find with any site is that without a good foundation you're bound to repeat same styles over and over, and with one you don't get any point with Tailwind.