Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Working with Tailwind CSS every day for 2 years

themosaad.com

Post reply on HN
Print view View original

71–80 of 215 posts

Re: Working with Tailwind CSS every day for 2 years

#71

Post by stephen »

whacked_new wrote: post #41
satvikpendem wrote: post #15

Having used Tailwind, once the class lists get large, it inevitably just becomes CSS classes again. My previous role had const headerStyles = ["bg-slate-100", "rounded-xl", "p-8" ...] ... ... and so on. So at that point, why use Tailwind anymore? Currently I use Vanilla-Extract, it's like SCSS but uses TypeScript instead of the SCSS language. It also compiles down into native CSS, so there's no runtime overhead like…

Thanks for the vanilla-extract recommendation, I'll be using this! In my case, tailwind was useful for providing a handy set of vocabularies for simple and common stylings. But once customizations start to pile on, we're back into SCSS. Using 2 systems at once meant additionally gluing them with the postcss toolchain, so effectively we have 3 preprocessors running for every style refresh. Looking in at TypeScript fro…

Fwiw to the avoid 80%-in-TW / 20%-in-SCSS-or-something-else dichotomy/complexity, we built Truss which brings TW (Tachyons) style abbreviations to the existing "something else" tool chain (Emotion in our case).

So then everything goes through a single system.

https://github.com/homebound-team/truss

> tailwind's and SCSS's VS code integration is pretty amazing

We get that too, by being just vanilla TypeScript, no editor-specific integration necessary. :-D

(I've linked to Truss in another response, so will stop now. :-))

Re: Working with Tailwind CSS every day for 2 years

#72

Post by cactus2093 »

734129837261 wrote: post #22

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…

> 3. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches.

I'm not necessarily a big fan of Tailwind, but this is a total strawman. Nobody would advocate having one big file with thousands of repeated classes or something. Just like it would be a strawman against the use of css variables to say that you'll end up with a bunch of global variables used in thousands of places that become impossible to change because you can't be sure you won't break something unintentionally. And in the extreme cases where it does happen, the latter scenario is often much worse of a problem IMO than having too much repetition, you can always get clever with find and replace to get through repetition.

Tailwind works when you use it with a component framework, you're not getting rid of all abstractions completely you're just moving them all to a single layer within the component class.

But both approaches still make it possible to shoot yourself in the foot and end up with a mess of unmaintainable code if you don't abstract things well.

Re: Working with Tailwind CSS every day for 2 years

#73

Post by alayek »

AlwaysRock wrote: post #12

I've been using it regularly for the last 6 months and like it a lot. The blog points out the biggest switching over issues. Converting from rem to px can be annoying if you cant do that math in your head and at first you are often looking up the "simple" tailwinds way to write a css property that you already know. I pretty much always have the tailwinds docs open and thankfully they are very good and searchable. It…

Regarding rem px conversions, I follow this intuition: _multiply by 4 gives you px value, dividing by 4 gives you rem value._

`h-8` utility is height of 8 * 4 = 32px or 8 / 4 = 2 rem.

Since design systems are supposed to be consistent, 4px is typically considered 1 unit of distance.

However, there are times when I might encounter values in Figma (or get inputs from designer) that won't allow me to use this easily.

Say, designer wants a max-width of 252px on an element. I usually use Alfred app on my work MBP to divide it quickly by 16 (since 1 rem is 16px under normal font-size settings), but you can use any calculator, even the one in Google search or DDG search.

It turns out to be a fraction, and in this case, it's 15.75 rem.

I use utility like `max-w-[16rem]`, closest consistent dimension that's a multiple of 1rem, and ship a pull request preview to the designer, asking for design feedback.

Chances are, designer agrees to stick to 16rem, and we ship it as is. If this width of 16rem, or closer values within the 250px vicinity, are used in other places in the design system components or our app; I'd typically add that to the Tailwind config as well.

Most of the time question of rem px conversion comes into picture because we look at design dimensions in Figma / Sketch / Indesign etc. tools, and try to implement the same in our UI code.

But this would only slow down a developer, switching back-and-forth between design and implementation.

What I find more productive while prototyping a UI (or a smaller component), is to just "eye it", instead of getting actual pixel-values right at the first go.

From just eye-ing it, I can make a guess if it should be h-3 or h-4 (you can also guess the right value using a binary search style heuristic), and if my implementation looks bigger (or smaller) than the design, I'd adjust accordingly.

Only after I've implemented a basic prototype of the UI component, I'd cross-check with the design tool, and edit some utilities if necessary to get as close to the design as possible.

Re: Working with Tailwind CSS every day for 2 years

#74

Post by kypro »

onion2k wrote: post #29
734129837261 wrote: post #22

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.…

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 naming of their utility classes is even worse.

For smaller projects or for prototyping it's okay, although even then it's only slightly better than inlining styles.

Re: Working with Tailwind CSS every day for 2 years

#75

Post by troysk »

philliphaydon wrote: post #20
pewpewyouhit wrote: post #19

Earlier quoted context omitted.

It’s pretty new though. Less than 2 years I think.

I was just shocked. Last night I’m like “hmm need to maintain aspect ratio on this box. Maybe I can use calc and vh or something. And this shocked up in Google. Rocked my world. I wanna go back across a bunch of products I’ve worked on over the years to fix stuff using this! One of my favourite features now!

It is definitely magical! So many hours saved trying to find the right responsive break points for those particular card UIs.

Re: Working with Tailwind CSS every day for 2 years

#76

Post by unsupp0rted »

nightski wrote: post #53
unsupp0rted wrote: post #24

Earlier quoted context omitted.

Same feeling here. In Tailwind, I'll use a `p-3` or a `.flex.items-center` all day, but making a nice button is such a slog, since I'm coming from a Vuetify background. Vuetify also has the same layout classes as Tailwind, like `pa-3` and `.d-flex.align-center` I use Vuetify + Pug (instead of raw HTML templates), so I get to make buttons like this: v-btn(outlined color="accent" @click="handleClick") Do Stuff or a Dat…

I mean what is stopping you from making a Button component once w/ Tailwind similar to Vuetify?

I've used probably 50~80% of Vuetify if taking together the last dozen projects I've done.

I'd basically have to re-implement all of Vuetify in Tailwind, from buttons to chips to toggles to alerts, etc?

The v-data-table is like 10 sub-components stuck together, each of which I'd have to re-implement with walls of Tailwind classes.

Re: Working with Tailwind CSS every day for 2 years

#77

Post by [deleted] »

onion2k wrote: post #29
734129837261 wrote: post #22

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.…

[deleted]

Re: Working with Tailwind CSS every day for 2 years

#78

Post by 1123581321 »

lloydatkinson wrote: post #23

Oh two tailwind hate threads today instead of the usual one at a time? Everyone as usual saying "long class lists" even though the literal home page tells you not to do this and to make components or partial views or whatever your tool of choice calls it. At least be inventive and follow the instructions before you start blaming something.

It's a lot of work to create components just to reduce CSS duplication (i.e. to create more components than you would make if you used traditional CSS classes.) Not always a good solution.

I do like Tailwind, for the record. It would be nice if its allies and enemies would both admit it makes tradeoffs.

Re: Working with Tailwind CSS every day for 2 years

#79

Post by anhner »

hbn wrote: post #50
bluetidepro wrote: post #39

Earlier quoted context omitted.

> 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 really don't get the "tailwind is for beginners" opinion I see parroted so much. It doesn't enable you to do anything that CSS didn't already do. It's just a different way of writing it. Knowing CSS is a prerequisite to being able to use Tailwind. "Tailwind is for beginners" just sounds to me like "I don't like this thing because I'm too smart for it"

> "Tailwind is for beginners" just sounds to me like "I don't like this thing because I'm too smart for it"

More like "I don't like this thing because I don't understand it, so I blame it on juniors because I feel superior to them, so I must be right"

Re: Working with Tailwind CSS every day for 2 years

#80

Post by eiiot »

734129837261 wrote: post #22

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…

> Spamming utility classes causes horrible git commits, git history, git difference checks;

As opposed to what? This is still an issue with any kind of utility class, where the alternative is inline styles or CSS-in-JS, both of which are substantially worse.

> Conflicting utility classes aren't clear, and sometimes the order cannot be trusted;

This is fixed in the IDE with tools like ESLint. I have VSCode setup to automatically reorder Tailwind classes, and it works great. (It even moves broken classes to the front of the list, so you can immediately identify if they're working or not)

> Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. And since there is no context to it, it'll be hard to JUST replace them where you would want them to.

This is an issue with CSS in general, especially CSS modules. Plus, if you use tailwind correctly (with @apply) you only have to update it once.

> Vanilla CSS using `:root` declaration, a fixed base size (using `rem` and `em`), CSS variables and `calc()` are SO powerful.

With tailwind, you still have access to `calc()` and variables with their bracket `[]` syntax. It's just much easier to do everything else.

Post reply on HN