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

111–120 of 122 posts

Re: Building React and Vue Support for Tailwind UI

#111

Post by nailer »

monkey_monkey wrote: post #91
nailer wrote: post #83

Earlier quoted context omitted.

so thinking of names like ‘author-nickname’ is difficult but learning an entire new syntax for css is easy?

Yes, "learning" the tailwind syntax was really quite easy. In addition, most editors and IDE's now have plugins for autocompletion And as an incentive to learning – once you're familiar with Tailwind's syntax, you get to use that learning on all your future Tailwind projects.

As a tailwind user I find it a hassle. There's quote of lot of CSS values, and having to remember small things like...

- 'grid-auto-flow: row' is 'grid-flow-row'

- 'grid-auto-flow: column' is not 'grid-flow-column' but rather 'grid-flow-col'

...is annoying.

Re: Building React and Vue Support for Tailwind UI

#112

Post by cageface »

nailer wrote: post #80
cageface wrote: post #51

Earlier quoted context omitted.

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.

Re: Building React and Vue Support for Tailwind UI

#113

Post by nailer »

kristiandupont wrote: post #103
welder wrote: post #29

Earlier quoted context omitted.

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.

Re: Building React and Vue Support for Tailwind UI

#114

Post by nailer »

cageface wrote: post #112
nailer wrote: post #80

Earlier quoted context omitted.

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.

Re: Building React and Vue Support for Tailwind UI

#115

Post by cageface »

nailer wrote: post #114
cageface wrote: post #112

Earlier quoted context omitted.

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.

@apply is your friend here.

Re: Building React and Vue Support for Tailwind UI

#116

Post by brundolf »

seer wrote: post #79
brundolf wrote: post #5

> We crawl this document as an AST, and actually transform it into four formats...The key to getting sensible output is really just having total control of the input format. It's still hard work, but when you can encode the intent of each example into a custom input format, converting that to another format turns out so much better than trying to write something that can convert arbitrary jQuery to React or something…

So true. The thing that put me on the path of discovering parsers was a tweet that said something to the effect of “if you want any relatively complex regex, what you actually need is a recursive descent parser”. Now as a self thought dev I haven’t really been shown in school what those were and always thought of them as some wizardly magic that only compiler writers dabble in. But after that tweet I looked around an…

I have a CS degree but we just never really covered parsing or compiling at all, for whatever reason (well... technically we talked about the formal theory behind grammars a little bit but we never did anything with it, and it hasn't really been useful at all)

But I always dreamed of making a programming language so one of my pandemic projects was to read Crafting Interpreters, and ever since then I've been a little bit obsessed

That's a great point about regexes! I'll have to keep that one in mind

Re: Building React and Vue Support for Tailwind UI

#117

Post by nailer »

cageface wrote: post #115
nailer wrote: post #114

Earlier quoted context omitted.

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

@apply is your friend here.

100% agreed that sharing styles with @apply is exactly how to solve this.

However Tailwind tells users they shouldn't be doing this, encouraging them to paste the same mixins on every element they want them.

Re: Building React and Vue Support for Tailwind UI

#118

Post by keithnz »

nailer wrote: post #81
keithnz wrote: post #57

Earlier quoted context omitted.

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…

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.

Re: Building React and Vue Support for Tailwind UI

#119

Post by nailer »

keithnz wrote: post #118
nailer wrote: post #81

Earlier quoted context omitted.

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…

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.

Re: Building React and Vue Support for Tailwind UI

#120

Post by keithnz »

nailer wrote: post #119
keithnz wrote: post #118

Earlier quoted context omitted.

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.
Post reply on HN