[welder]

This is so ugly and error prone:

<Button className="bg-gray-100 rounded-full flex" ...

How do you remember the names of all your classes? Should your IDE know about these classes? Can you autocomplete class names? Where's the import statement for these classes so you know where they're defined and what they do. There's a better way:

Use site-wide themes (Objects with keys like colors.heading.primary having value '#000') and withStyles[1] and React.PureComponent[2]. Having your React component render the same result given the same props and state makes things so much easier to work with. Also, the compiler knows about your theme so your IDE helps auto-complete and makes sure the style you're using is actually defined.

[1] https://github.com/airbnb/react-with-styles

[2] https://reactjs.org/docs/react-api.html#reactpurecomponent

[lxe]

> Should your IDE know about these classes? > Can you autocomplete class names?

Yes! (https://marketplace.visualstudio.com/items?itemName=bradlc.v...)

Although I wouldn't mind an array instead so I can use the typescript typechecker.

[welder]

You get type checking automatically using withStyles, no plugin needed. That plugin is kinda cool with the css preview feature, but I bet using the built-in IDE autocomplete is more reliable. I also find withStyles more readable in general, for ex:

theme: {

  button: {

    primary: {

      color: 'blue',

      padding: '2px',

    },

  },

}

<Button {...css(theme.button.primary)}>

vs. tailwind classes:

<Button className="text-blue p-2">

[ahuth]

You don't need to remember all the classes. Instead, you can go to https://tailwindcss.com/docs and search for whatever you're looking for.

Having IDE autocompletion (or even TypeScript integration) would be really nice. I'm sure there's plugins for many IDEs or editors that can do that, though.

[nailer]

As a tailwind user, looking them up every time, especially when you a already know the CSS, isn’t that great an experience either.

[welder]

> Having IDE autocompletion would be really nice. I'm sure there's plugins that can do that.

Use withStyles [1] and vscode autocompletes without needing a plugin.

[1] https://github.com/airbnb/react-with-styles

[lights0123]

VS Code and IntelliJ plugins provide just that, and the VS Code plugin goes further by showing the CSS it will expand to and show a color preview next to the class name.

[jamesiscool]

So does the IntelliJ one, with a hover I think

[nailer]

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)`.

[city41]

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.

[nailer]

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.

[cageface]

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.

[nailer]

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.

[cageface]

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.

[lights0123]

So make it. Add it to your tailwind.config.js: https://github.com/lights0123/lights0123.github.io/blob/7df7..., then use some CSS variables: https://github.com/lights0123/lights0123.github.io/blob/7df7...

[nailer]

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.

[welder]

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.

[kristiandupont]

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

Clearly, not "everyone" stopped doing that.

[nailer]

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.

[keithnz]

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.

[nailer]

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.

[keithnz]

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.

[nailer]

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.

[keithnz]

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.

[lampe3]

I'm with you here.

Tailwind is easy to start but hard to maintain and extend.

Its good for a prototype or small landing page.

I would never use it for long term project where you need to maintain and extend your features a lot.

[leadingthenet]

> How do you remember the names of all your classes?

You don't.

https://tailwindcss.com/docs/extracting-components

[welder]

So, the dev never reads/modifies the extracted component that still uses hard-to-read hard-to-typecheck classes? Doesn't seem like a good solution.

[gervwyk]

It’s a great solution. Every class only maps to one css property setting, and they are very well named.

Thus not much more difficult to read and remember than css key value pairs.

Why would you typecheck component class names? If so, its all strings, seems pretty easy less error prone than inline styles.

[aniforprez]

Actually each class does NOT always map to a single property. In what I consider to be its greatest strength each class is actually designed to do some very specific thing that can actually require multiple CSS properties and settings. For eg the breakpoint classes are fairly complex but allow you incredible flexibility in building responsive UIs