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

81–90 of 122 posts

Re: Building React and Vue Support for Tailwind UI

#81

Post by nailer »

keithnz wrote: post #57
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…

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.

Re: Building React and Vue Support for Tailwind UI

#82

Post by rwieruch »

Super interesting to read this. Especially how you eventually bridged HTML to React/Vue. Thanks for sharing!

One year ago I had to do something similar and used Web Components (https://www.robinwieruch.de/react-web-components). Did you consider using Web Components or a Web Components library such as lit-html in the first place?

Re: Building React and Vue Support for Tailwind UI

#83

Post by nailer »

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…

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

Re: Building React and Vue Support for Tailwind UI

#84

Post by ssijak »

crad wrote: post #11
ssijak wrote: post #4

Or just use something like Chakra UI, which is like Tailwind CSS but based on styled system and built with Typescript for React from the beginning and has a nice set of basic components. I even built something like Tailwind UI but for Chakra (link is in my bio if you want to check it out)

I think you missed the point as an opportunity to pitch your project.

Not really. I like TailwindCSS, I used it in several smaller projects before. But then I found about Styled System and later ChakraUI and never looked back. I really think ChakraUI is TailwindCSS on steroids for React and recommend everybody who is working with React to at least check it out.

Re: Building React and Vue Support for Tailwind UI

#85

Post by sbacic »

ahuth wrote: post #47
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 o…

> It's not, because there's a system to it.

I think what bothers people isn't _what_ it is but _where_ it is. I for one, don't want long sausages in my HTML elements, regardless of whether they are classes or CSS styles.

Re: Building React and Vue Support for Tailwind UI

#87

Post by fnordsensei »

ssijak wrote: post #4

Or just use something like Chakra UI, which is like Tailwind CSS but based on styled system and built with Typescript for React from the beginning and has a nice set of basic components. I even built something like Tailwind UI but for Chakra (link is in my bio if you want to check it out)

As someone living in ClojureScript land, I’m really happy that someone is giving me a decomposed/decomplected option for these things.

Headless UI is some of the nicest React components I’ve worked with via interop, and to me it’s really valuable that they don’t come with an opinionated way of styling them.

Re: Building React and Vue Support for Tailwind UI

#88

Post by pbowyer »

tasogare wrote: post #65
willhoyle wrote: post #61

This is great work, congrats on shipping a great product. I use TailwindCSS on my personal website. I often wonder whether we need yet another UI framework implementation? I touched on this in my post a couple days ago: https://williamhoyle.ca/blog/2021/vue-has-too-many-ui-framew... To summarize: We have 20+ UI frameworks written in Vue. Surely there's enough common ground/code to combine the implementation details f…

> I often wonder whether we need yet another UI framework implementation? Because the web wasn’t designed for applications UI interfaces (hence the CSS grid which landed only in 2017), so it lacks basic primitives and behaviors that are then re-implemented slightly differently by different people. On the contrary, a UI framework designed for this such as the Windows Forms on Windows desktop is still very usable (and…

There is an ongoing effort at https://open-ui.org/ to add these basic primatives. I'm throwing my effort behind the replacement and we welcome input from everyone.

If I can avoid writing another autocomplete and solving the Esc corner cases, the effort will have been worthwhile...

Re: Building React and Vue Support for Tailwind UI

#89

Post by pansa2 »

JohnCurran wrote: post #67
pansa2 wrote: post #59

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…

Look in to alpine.js - pairs very nicely with Tailwind

Thanks - Alpine.js looks like an appropriate choice in general, but unfortunately it’s not supported by these particular components. However, the announcement does say “we're looking forward to exploring other frameworks in the future (Alpine.js is next on our list)”.

I’d be interested to know whether Alpine.js support is “coming soon” or “maybe eventually”.

Re: Building React and Vue Support for Tailwind UI

#90

Post by mariusmarais »

willhoyle wrote: post #61

This is great work, congrats on shipping a great product. I use TailwindCSS on my personal website. I often wonder whether we need yet another UI framework implementation? I touched on this in my post a couple days ago: https://williamhoyle.ca/blog/2021/vue-has-too-many-ui-framew... To summarize: We have 20+ UI frameworks written in Vue. Surely there's enough common ground/code to combine the implementation details f…

I think a big part of the problem is that probably 12x of those have to re-implement because they want to change something unrelated like styling, or want to add more components, but can't extend existing libs without using the same styling, so they end up re-doing everything.

So we end up with 20x libs all doing roughly the same thing, sometimes badly.

This one doesn't seem like the typical Munroe +1, because it's not trying to rule them all, just put a visually unopinionated base in place with the tricky, boring stuff handled. It kinda feels like other libs are doing too much in any case.

Post reply on HN