Live data from Hacker News

Working with Tailwind CSS every day for 2 years

themosaad.com

81–90 of 215 posts

Re: Working with Tailwind CSS every day for 2 years

#81
I recently came to the conclusion that the best way to write CSS is through a Design System and write all the CSS yourself. And when I say Design System - I mean it can be your own or it can be external.

The problem with writing a lot of CSS is that you will eventually run in circles and repeat yourself on the same elements with only small differences. A design system lets you adjust it all at once through Variables, and as of recently - some of the more powerful Selectors and Pseudo-classes.

It also makes it easier to switch a design so you don't inherently lose all your work.

I don't have a strong opinion on Tailwind CSS because I don't use it but I am familiar with it. I know it hasn't been adopted inside CMS's all that much, but it is very popular when it comes to things like individual elements (cards, headers, etc.) because those individual elements will work universally across any Tailwind project.

Re: Working with Tailwind CSS every day for 2 years

#82

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Rep…

Pretty much every CSS framework I've ever seen (and certainly every CSS-in-JS solution I've ever seen) has as its underlying premise "we know you hate CSS, and want to avoid thinking about it as much as possible". For people like me (and perhaps you) who actually like CSS, our reaction is "why would I ever want to use something that abstracts away the power and flexibility of a thing I enjoy using?" The problem is th…

> Pretty much every CSS framework I've ever seen (and certainly every CSS-in-JS solution I've ever seen) has as its underlying premise "we know you hate CSS, and want to avoid thinking about it as much as possible". For people like me (and perhaps you) who actually like CSS, our reaction is "why would I ever want to use something that abstracts away the power and flexibility of a thing I enjoy using?"

I don't find this to be the case with styled-components. To me styled components feels just like writing CSS (which I like), but with a slightly obscure variable syntax (if I need a prop or theme value).

Re: Working with Tailwind CSS every day for 2 years

#83
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.

Re: Working with Tailwind CSS every day for 2 years

#84

Earlier quoted context omitted.

How does it not get in your way? If you ignore it?

It gives you a consistent design system with sensible defaults and easy-to-use (and rather memorable or easy to deduce) utility classes. Unlike the yet-another umpteenth bespoke `.card-header__buttons .card-header__button--secondary` that no one can remember and create an umpteenth+1 Tailwind works great when your site/app is a collection of components

`.card-header__buttons` that example makes no sense unless you use global CSS/SASS, which very few projects do anymore. Component CSS/SCSS or CSS-in-JS are very common which resolve this scoping problem.

So why bother with a DSL like Tailwind over Component CSS/SCSS for example?

Re: Working with Tailwind CSS every day for 2 years

#85
post #68

I'll be honest here, after working with tailwind for 7 months I really hate this piece of tech and really regret picking this company. I thought it wouldn't be a big deal but after seeing unnecessary long walls of class names I'm really tired. Anything other than basic styling is an absolute pain with tailwind and I don't understand why /my company specifically/ can't just use typestyle/styled-components/css modules…

If you dislike walls of class names, you could consider using Tachyon's style abbreviations like we do in Truss: https://github.com/homebound-team/truss

From that link:

`...;`

That must be one of the most horrid things I've ever seen done to CSS.

Re: Working with Tailwind CSS every day for 2 years

#86

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Rep…

You're welcome to hate tailwind all you want, but don't let that cloud your judgement.

Plenty of very experienced developers like it just fine.

Re: Working with Tailwind CSS every day for 2 years

#87
post #29

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Rep…

It's loved by novices and those who don't know what they're doing, almost exclusively. I've been a frontend dev for 25 years and I quite like Tailwind. I'm not sure which category I fit into. I think it might be both. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. This is a really good example of where Tailwind is actually quite nice.…

They "No true Scotsman" started their argument, so I think you're fighting uphill.

I have around 10 years experience, tailwind is a godsend for maintainability and speed.

Re: Working with Tailwind CSS every day for 2 years

#88

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Rep…

> It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. This is an incredibly silly take. As a senior frontend dev with almost 20 years of experience and a solid resume, I will take Tailwind over anything else in most cases. Obviously there is always exceptions based on the project needs, but to have such a hard take like…

I have 20 years of front end dev work and consider myself a CSS novice as I think the overwhelming majority of people are.

If you haven’t read and understood the spec then like most people you don’t know CSS, which is fine. It’s not a question of knowing what say conic-gradient does, but how browsers use CSS in depth.

Re: Working with Tailwind CSS every day for 2 years

#89
post #74
post #29

Earlier quoted context omitted.

It's loved by novices and those who don't know what they're doing, almost exclusively. I've been a frontend dev for 25 years and I quite like Tailwind. I'm not sure which category I fit into. I think it might be both. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. This is a really good example of where Tailwind is actually quite nice.…

Variables would be the obvious answer here. If you're applying `p-4` to all your component classes you're only marginally improving on applying `padding: 8px` on all of your component styles. Both are terrible solutions even if one is slightly better than the other. I generally agree with OP. Tailwind is horrible for larger projects and I have no idea why it's so well liked. The utility class approach is bad, and nam…

But p-4 is a variable: you can set the actual padding applied in the configuration file! It doesn’t have to mean 8px, but rather „standard amount of padding“. If you want to use „small amount of padding later on, you’ll use p-2 - whatever that means in your app.

That solves the exact problem you and OP complain about, in a neat, configurable, safely replaceable way. Tailwind allows you to separate design intent from implementation values.

Re: Working with Tailwind CSS every day for 2 years

#90

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Rep…

> It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. This is an incredibly silly take. As a senior frontend dev with almost 20 years of experience and a solid resume, I will take Tailwind over anything else in most cases. Obviously there is always exceptions based on the project needs, but to have such a hard take like…

I've been doing front-end development in some capacity almost as long as you, but it's not my forte. I've looked at Tailwind and I can see its value as a way to quickly prototype, but it also looks to violate the deeply instilled belief I have about semantically named classes. I know front-end development has changed its set of best practices several times now. We went from unobtrusive JS and semantic class names to modular CSS and CSS in JS, along with heavily marked up HTML to help out JS frameworks. Maybe this is just the pendulum swinging again. But, I'd appreciate any insights you can share on how this helps lead to maintainable software. The string of utility class names on various elements doesn't click for me the same way a class named "sidebar" or whatever would. But, a lot of smart people like it, so I assume I must be missing or overlooking something.
Post reply on HN