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

Building React and Vue Support for Tailwind UI

blog.tailwindcss.com

Post reply on HN
Print view View original

41–50 of 122 posts

Re: Building React and Vue Support for Tailwind UI

#41

Post by mike1o1 »

734129837261 wrote: post #38

Tailwind is the weirdest thing I've ever ran across. It's basically inline CSS. Personally, I write CSS this way: 1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames. Only when you have troubles selecting an element based on its position in your DOM you should choose a classname. It should not be ".text-gray-500" (like Tail…

This comes up almost every time, but it's not "basically inline CSS". The best thing about Tailwind (and utility classes in general) is that it forces you to use consistent measurements across your app.

"Shoot, was this 13px padding or 14px padding on the other page?" Don't worry about it, just use "p-4, p-6, etc.". Thinking in these terms becomes really powerful.

Another great thing as that you just simply don't have to think about what to name things! I find that so liberating, to be honest, and I don't have to keep switching back and forth between my markup and my css. I don't have to worry about coming up with semantically descriptive names. I just use "text-gray-500". Was this .authorrole? Or was it .authoremail? Hmm, now I want to display an author nickname. Do I just repeat "authorname" class? I find it so freeing to basically not have to worry about this stuff at all.

Re: Building React and Vue Support for Tailwind UI

#42

Post by mpalmer »

734129837261 wrote: post #38

Tailwind is the weirdest thing I've ever ran across. It's basically inline CSS. Personally, I write CSS this way: 1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames. Only when you have troubles selecting an element based on its position in your DOM you should choose a classname. It should not be ".text-gray-500" (like Tail…

The semantically descriptive unit for most Tailwind users is the React/Vue/Angular component. For vanilla web development it definitely makes less sense, especially since it has a "compile" step.

Re: Building React and Vue Support for Tailwind UI

#43

Post by nailer »

lights0123 wrote: post #36
nailer wrote: post #25

Earlier quoted context omitted.

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…

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

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.

Re: Building React and Vue Support for Tailwind UI

#44

Post by tomc1985 »

734129837261 wrote: post #38

Tailwind is the weirdest thing I've ever ran across. It's basically inline CSS. Personally, I write CSS this way: 1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames. Only when you have troubles selecting an element based on its position in your DOM you should choose a classname. It should not be ".text-gray-500" (like Tail…

Pretty much every CSS framework under the sun relies on a pile of classnames for each element? Even the most mimimal frameworks from 10 years ago worked this way...

Re: Building React and Vue Support for Tailwind UI

#45

Post by themarkn »

734129837261 wrote: post #38

Tailwind is the weirdest thing I've ever ran across. It's basically inline CSS. Personally, I write CSS this way: 1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames. Only when you have troubles selecting an element based on its position in your DOM you should choose a classname. It should not be ".text-gray-500" (like Tail…

If you see it as just inline CSS, then tailwind can be avoided for all the same reasons that we avoid writing inline CSS. It’s considerably more than inline CSS imo but that’s a different story.

That said, I’m surprised by this:

“Only when you have troubles selecting an element based on its position in your DOM you should choose a classname”

Certainly if you have knowledge of the exact DOM structure in advance, and high confidence that it will never be substantially changed, this is workable. But in many cases, having the CSS care about the DOM structure produces way more pain than the ergonomics of tailwind do. At least in the kind of code I’ve worked on where components are reused all over the place and sometimes rearranged by authors directly in a CMS. Or just having DOM reorganized because something is added that requires an extra wrapper & then all the CSS selectors are nested wrong. Or whatever.

Anyhoo. I don’t love tailwind, but I think it’s fine. Far worse things have happened to web dev. It seems like you have a problem with utility CSS, which tailwind takes to the extreme for sure.

Also, side note - having headings in a figcaption like that seems semantically incorrect.

Re: Building React and Vue Support for Tailwind UI

#46

Post by nailer »

city41 wrote: post #32
nailer wrote: post #25

Earlier quoted context omitted.

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…

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

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.

Re: Building React and Vue Support for Tailwind UI

#47

Post by ahuth »

734129837261 wrote: post #38

Tailwind is the weirdest thing I've ever ran across. It's basically inline CSS. Personally, I write CSS this way: 1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames. Only when you have troubles selecting an element based on its position in your DOM you should choose a classname. It should not be ".text-gray-500" (like Tail…

> It's basically inline CSS.

It's not, because there's a system to it. With Tailwind you pick specific values. Inline styles let you specify any value.

> It should not be ".text-gray-500" (like Tailwind does)

This is fair. I'd never considered that specifying the actual color in the class name would be problematic, but another thread pointed out that it makes theming (such as dark mode) difficult.

> 1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames.

I'm sure this works great when there are a small number of people working on styles. When there are many, however, I've found that the cascade often results in styles overriding one another, and needing to introduce more specificity to fight it, in an endless cycle.

Obviously people should write better CSS to avoid that. Which is actually what Tailwind is, I think.

Re: Building React and Vue Support for Tailwind UI

#48

Post by nailer »

ahuth wrote: post #28
welder wrote: post #23

This is so ugly and error prone: 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]. Havi…

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.

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

Re: Building React and Vue Support for Tailwind UI

#49

Post by natural219 »

franciscop wrote: post #30
natural219 wrote: post #21

Earlier quoted context omitted.

Blurring the line between attributes/react props and CSS classes seems abhorrent to me, but just my two cents

Sure in this "extreme" I'll agree, it was just an experiment after all (I do think both the short-hand classes and attributes look wrong). Do you think the same about either of these? Hello Hello

I dislike both of these :). Just leave the styling layer to itself.

Re: Building React and Vue Support for Tailwind UI

#50

Post by welder »

mike1o1 wrote: post #41
734129837261 wrote: post #38

Tailwind is the weirdest thing I've ever ran across. It's basically inline CSS. Personally, I write CSS this way: 1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames. Only when you have troubles selecting an element based on its position in your DOM you should choose a classname. It should not be ".text-gray-500" (like Tail…

This comes up almost every time, but it's not "basically inline CSS". The best thing about Tailwind (and utility classes in general) is that it forces you to use consistent measurements across your app. "Shoot, was this 13px padding or 14px padding on the other page?" Don't worry about it, just use "p-4, p-6, etc.". Thinking in these terms becomes really powerful. Another great thing as that you just simply don't hav…

There's a better way to get consistent measurements without having to remember class names:

Use withStyles[1] and have a spacings namespace in your theme. Use the spacing in your component like spacing.button, which applies an Object containing the correct CSS padding, or spacing.padding.medium for the raw number.

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

Post reply on HN