ok
I don't recommend Tailwind CSS
81–90 of 179 posts
Re: I don't recommend Tailwind CSS
#82This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…
Projects with a single gigantic CSS file also work and you can onboard people etc. That's not an argument.
Re: I don't recommend Tailwind CSS
#83This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…
I wouldn't even write such a class name. It smells like bad styling and layouting already. A CSS class should convey some semantic meaning. I would name it after the thing that should be red or green, not "red"/"green". That doesn't tell me anything. Maybe its name could be something like "danger" or "active" or something. Also the 500 looks very sus. Responsive design is best when it avoids such hardcoded numbers an…
Absolutely not. Semantic classes are the wrong way to go. Your components (and their props API) are what encode the semantics. With Tailwind you never need to try to come up with a name for anything relating to style, you just use utility classes. It reduces cognitive load significantly.
Re: I don't recommend Tailwind CSS
#84As a 26+ year frontender, years ago I was against it on so many levels. Until I tried it. Never looked back. Also, inheriting projects with someone else’s code is fine. Just a quick look at the central config and you’re good to go.
Totally agree. It does break the rules, but it feels so much faster than defining class names.
On simple projects I usually @apply tailwind styles to standard elements like headings, block quote, aside, nav etc. Then just use semantic html.
Looks good and takes so little effort.
Re: I don't recommend Tailwind CSS
#85Earlier quoted context omitted.
The fact that “text-red-500 text-green-500” resolves by stylesheet source order rather than anything visible in the markup means the “locality of behavior” promise quietly breaks exactly when you compose components dynamically, which is why tailwind-merge exists at all, and needing a runtime dependency to answer “which of my two classes wins?” is a real design smell, not a bikeshed.
That is kind of my point, though—you don't need tailwind-merge, really. There are two cases it solves: One, adding classes from the outside to an encapsulated component with its own, internal classes, to make sure the outside-applied classes take priority. Either use the !important modifier on them (`ms-auto!`), put the components into a container div with the classes for layout concerns, or even better: Figure out w…
I would reach for class-variance-authority (aka cva) instead for stuff like a size prop, it declaratively solves that.
Re: I don't recommend Tailwind CSS
#86This discussion again. We've been having it for 6 years now and Tailwind remains popular. Lindy's Law tells us it will remain popular for a while longer.
Many people are productive in it, others hate it. Carry on.
Re: I don't recommend Tailwind CSS
#87As a 26+ year frontender, years ago I was against it on so many levels. Until I tried it. Never looked back. Also, inheriting projects with someone else’s code is fine. Just a quick look at the central config and you’re good to go.
Tailwind looks bad on "paper". It violates a lot of "best practices". It is ugly. Yet in reality it works. It gets the job done. It is fast to work with. Constraints are known to enhance creativity.
My constraint is "use vanilla CSS" ;) I made a huge solo project in tailwind. Never again. Vanilla CSS is perfectly fine for my own uses. In fact, I've gone a whole 'no classes' style and used as much semantic HTML and modern CSS and can get extremely far. No more looking into the tailwind docs to learn its syntax on a modern vanilla CSS feature that I've been waiting for.
Re: I don't recommend Tailwind CSS
#88This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…
Projects with a single gigantic CSS file also work and you can onboard people etc. That's not an argument.
they do work… for any value of work. I have been in the industry for a while, and I've never seen a project which doesn't slowly devolve into fights with the cascade over time - arbitrary abstraction layers, ad-hoc organization patterns, developer-specific conventions, inconsistent naming, and so on. All of this usually creeps in the more a project grows. At some point, someone adds postcss or scss or another preprocessor and starts splitting files, and then a whole new set of new, made-as-you-go conventions comes in: Files per component or per view? Or rather per architecture concern? Usually a mix of them. As files are split, the class naming gets even more inconsistent.
And at that point, onboarding a new developer always means wasted time on understanding this whole organically grown set of bespoke conventions, class names, patterns, hierarchies, and so on.
Tailwind does not really have this pattern of deterioration growing along both time and complexity, it stays consistent on both axes. So it's definitely an argument IMHO.
Re: I don't recommend Tailwind CSS
#89What's so strange with Tailwind users is how insistent they are to impose it to codebases they don't know. I've never seen this even with vue vs react. People that didn't write lines of code on this project, or so. A few months later, your codebase has very long lines of HTML with classes that encode a whole programming language as strings separated by spaces, and barely no component anymore, nor semantic CSS tags.
Your complaint is about bad developers, not about Tailwind. Using Tailwind correctly means making heavy use of components to avoid duplication. Using Tailwind also removes the burden of having to do one of the hardest things in software: naming things, which is what semantic classes requires you to do.
Re: I don't recommend Tailwind CSS
#90Earlier quoted context omitted.
That is kind of my point, though—you don't need tailwind-merge, really. There are two cases it solves: One, adding classes from the outside to an encapsulated component with its own, internal classes, to make sure the outside-applied classes take priority. Either use the !important modifier on them (`ms-auto!`), put the components into a container div with the classes for layout concerns, or even better: Figure out w…
I would reach for class-variance-authority (aka cva) instead for stuff like a size prop, it declaratively solves that.
Interesting, I didn't know that project yet! I'll give it a thorough read.