Hacker News new | ask | show | jobs
by nailer 1891 days ago
Love this. And anything else that uses design systems rather than styling individual elements.

I currently have a tailwind project that's around twelve months old. I'd like to add a dark theme.

Normally - in a CSS, SCSS, PostCSS project - this would consist of adding a media query overriding a handful of color variables.

Using tailwind (which has 'inbuilt dark mode support') I have a few thousand colors spread around the project and I have to modify them all. Additionally by having a giant palette of named colors, we have, for example, multiple occurrences of our active color as `blue-400` and `blue-500` and `blue-600` rather than a single `var(--active-color)`.

4 comments

Tailwind out of the box is a simple, canned design system. The Tailwind authors have already decided your color palette, spacings, animations, etc. This is perfectly fine for prototypes or anything that isn't that important. But if you want to have more ownership over the design system, it's better to use Tailwind's config and set it up as it makes sense for your site. Colors are the most obvious candidates, with Tailwind you can setup your own colors and from there do `bg-active` or whatever else makes sense for your site. You can define whatever is important for your site, and fall back to the inbuilt system for the things that aren't.
That’s definitely true. I just wish tailwind encouraged consistent styling (by having a design guide and variables) rather than styling individual elements in their documentation, which means someone has to clean up the mess later.
In practice I find UI built with Tailwind to be a lot more consistent because all the dimensions are built from standard values instead of custom dimensions for every css class. The bigger problem in my experience is that most designers are too lazy to set up a type and color scheme up front and just drag whatever looks good to them in their sketch/figma files.
You mention the issue being solved is having standard dimensions.

We’ve been doing this in CSS for quite some time using variables. This didn’t require adding a fairly leaky and thin abstraction on top of CSS and adding thousands of copy pasted singleton styles to our projects.

I have a few hundred tailwind classes left in my projects after a purge css pass. If you have thousands you probably should start looking into extracting some components. If you literally have "a few thousand" colors in your UI you need to find a new designer.

And CSS variables are great but way more verbose and still require you to come up with "semantic" names for everything.

> If you have thousands you probably should start looking into extracting some components.

This is confusing component reuse with design system reuse.

Two components may have completely different purposes, but they both have a certain rounding, palette, and other styles.

You’re missing the point. I’ve already enabled dark mode in the config file. But tailwind’s approach of styling elements individually means I have to clean up a few thousand lines of styling first.
Yep, design systems (your own component library) are the way to go with React. Auto-complete, type checking support, functional, etc. You do style the component once, but after that it's self-contained, reusable, and functional.

Everyone stopped using unstructured cryptic class="bg-gray-100" for good reason. Tailwind is backwards progress.

https://wptavern.com/state-of-css-2020-survey-results-tailwi...

Clearly, not "everyone" stopped doing that.

Not the OP but I suspect 'everyone' was hyperbole, and they actually meant 'professional frontend designers and engineers'.

Tailwind being popular doesn't really contradict their point.

see https://www.youtube.com/watch?v=MAtaT8BZEAo where they discuss how to do what you want. There probably could be better standard advice on how to make your setup a bit more future proof out of the box.
That video specifies to undo all the manual styling which tailwind encourages and that’s exactly what I’m doing.

The point is undoing single element styling would never would have been necessary if tailwind didn’t encourage styling single elements (saying that “best practices aren’t”) in the first place.

The author literally even mentions we should use “symantic descriptive names”. You know, like those best practices that tailwind says don’t work.

he is one of the tailwind guys, I don't think there advice is one size fits all, there are different scenarios where you want different things. The point they basically make is to make a design system using generated a utility first approach. Nearly everywhere in the their tutorials etc they encourage customization to your specific needs.
I know he’s one of the tailwind guys. That’s why I’m pointing out the inconsistency of a video stating semantic class names are needed for consistency, while having a website that strongly suggests otherwise.
Not really sure what you are referring to, they always seemed to be open ended, and their docs https://tailwindcss.com/docs/customizing-colors#naming-your-... seem to represent this. The main point is you need to customize your design system and tailwind provides a toolbox for doing that.