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

51–60 of 122 posts

Re: Building React and Vue Support for Tailwind UI

#51

Post by cageface »

nailer wrote: post #46
city41 wrote: post #32

Earlier quoted context omitted.

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.

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.

Re: Building React and Vue Support for Tailwind UI

#52

Post by bcrosby95 »

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

What does red apply to? The button color? The text color? Both (sounds useless)?

If you told me a button were red, I would assume the button is red and any decoration on it (e.g. text) isn't. Not sure if that's what happens here.

Re: Building React and Vue Support for Tailwind UI

#53

Post by extra88 »

tomc1985 wrote: post #44
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...

Bootstrap and the like don’t have one property per class name as Tailwind does.

Re: Building React and Vue Support for Tailwind UI

#54

Post by vehemenz »

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…

Tailwind is not "basically" inline styles.

Tailwind and other functional frameworks use classes for abstraction, which unlocks media queries, pseudo selectors, and many other CSS features.

Plus Tailwind's build system generates styles according to your config, which is sort of what distinguishes it from other functional frameworks.

"Semantically" descriptive could mean any number of things. In this case, it seems to mean: name your class according to what it's supposed to do, which is nice in theory, except that it hides the relationship between the markup and CSS. A well-prepared stylesheet is nice, except when the markup doesn't match what it expects.

In Tailwind, the class names themselves are "semantically" descriptive because they do exactly what they are supposed to do. There are no hidden abstractions.

Re: Building React and Vue Support for Tailwind UI

#55

Post by tshaddox »

mike1o1 wrote: post #9

Tailwind and Tailwind UI are really great. Tailwind UI as a series of blueprints is exactly what I'm looking for and I love how often they're updating and adding new blueprints to their list of components. This part from the blog post kind of confused me a bit, though. "The promise of Tailwind UI is that it's just a code snippet" Am I the only one who never looks at the code snippets/tab for Tailwind UI, and instead…

I’m the same way, but that’s because I don’t use Tailwind (the CSS library) and have no plans to use it. I just like the clean design work and some useful CSS techniques and tricks in Tailwind UI!

Re: Building React and Vue Support for Tailwind UI

#56

Post by vehemenz »

themarkn wrote: post #45
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 h…

> having headings in a figcaption like that seems semantically incorrect.

I genuinely wonder what the payoff is for semantic correctness.

Web browsers don't care, screen readers aren't nearly as particular as they used to be, and the web certainly isn't returning to some XML/XSLT universal document ideal.

Re: Building React and Vue Support for Tailwind UI

#57

Post by keithnz »

nailer wrote: post #25
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…

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…

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.

Re: Building React and Vue Support for Tailwind UI

#58

Post by themarkn »

vehemenz wrote: post #56
themarkn wrote: post #45

Earlier quoted context omitted.

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

> having headings in a figcaption like that seems semantically incorrect. I genuinely wonder what the payoff is for semantic correctness. Web browsers don't care, screen readers aren't nearly as particular as they used to be, and the web certainly isn't returning to some XML/XSLT universal document ideal.

A screenreader user cares if they are navigating between headings and the headings are not actually headings - and it’s always _better_ if the nature and structure of the content is expressed in the HTML so that the screened can announce things correctly. Keyboard users also care a lot about semantic HTML because they are so so many interfaces out there that are not keyboard navigable as divs are used for everything including buttons. So they just can’t reach parts of the interface, or even perceive them.

It’s not about a pristine ideal. Though I’d argue semantic HTML is not only the foundation of good accessibility, it also makes for more readable code because the intention behind the elements is exposed to the next person reading it. It nudges you to do better work because you actually have to understand the nature of what you are building, which means you might see how it reflects an existing pattern that can be copied, not duct tape together a half working tab interface with JS event listeners on divs and spans.

Re: Building React and Vue Support for Tailwind UI

#59

Post by pansa2 »

I'm currently using Tailwind CSS to style a fairly simple static website that's being generated using Hugo. I've been considering using some Tailwind UI components, e.g. modals (in particular, lightboxes to show zoomed-in versions of images).

I assumed that I would use Tailwind UI's HTML for these and write vanilla JS for interactivity, but now I am rethinking, especially having read this quote in the article: "If we tried to write it in custom vanilla JS, well we'd be making it harder for literally everyone".

So given this announcement, in my situation would you recommend against vanilla JS, and instead to adopt one of React or Vue?

Re: Building React and Vue Support for Tailwind UI

#60

Post by anitil »

Scarbutt wrote: post #8
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…

One tends to think of parsing/compiling as a fairly esoteric skillset that a relatively small number of programmers Parsing is the easy/not so interesting part of a compiler.

Someone on here made the comment a little while ago that while that is true for compiler makers, parsing is the much more useful skill for the average programmer. It allows you to approach a new realm of problems that are otherwise off limits.

So while looking back it may seem like a gentle incline, to a lot of us looking forward it is a steep cliff.

Post reply on HN