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

Don't use Tailwind for a design system (2021)

sancho.dev

Post reply on HN
Print view View original

161–164 of 164 posts

Re: Don't use Tailwind for a design system (2021)

#161

Post by redbar0n »

akvadrako wrote: post #158
satvikpendem wrote: post #5

I've used Tailwind extensively at previous companies and inevitably each one creates an abstraction that's akin to: const headerClasses = [(list of Tailwind classes here)]; ... because the complexity of reading and writing all of the classes is just too much. At that point, you've just reinvented CSS classes. Tailwind fans will tell you to not do this but if multiple companies are independently having the same proble…

Attributify mostly solves readability issue: https://windicss.org/features/attributify.html

It solves the repetition and collation into className, yes.

But I think the author's main gripe was that component abstraction was made difficult with Tailwind when you want to customize the component from the outside, by dynamically altering the styles through props (as often needed for contextualization in design systems), and not just no-prop components like Tailwind suggests: https://tailwindcss.com/#component-driven

Re: Don't use Tailwind for a design system (2021)

#162

Post by redbar0n »

neximo64 wrote: post #14

These sound like gripes with React more than tailwind.

I think they are gripes from trying to combine the bottom-up approach of Tailwind with the top-down approach of props based styling that JS component libraries typically allows. His point being that Tailwind does not work too well with such solutions for dynamism / contextual style overrides. You could solve it with using clsx or cva though, as seen in this video: "Tru Narla: Building a design system in Next.js with Tailwind" https://www.youtube.com/watch?v=T-Zv73yZ_QI

The best way seems to be making styling a completely internal component concern, and not take in style props but simply semantic props like isActive=true and then have the component itself apply styles based on that, like NavItem.js on the Tailwind home page suggests: https://tailwindcss.com/#component-driven

This practise is elaborated in this example has the same button styled differently by passing in different semantic props: https://youtu.be/T-Zv73yZ_QI?t=570

Re: Don't use Tailwind for a design system (2021)

#163

Post by redbar0n »

lyxsus wrote: post #145
redbar0n wrote: post #121

Earlier quoted context omitted.

Have you seen "The modern way to write TypeScript"? https://github.com/DanielXMoore/Civet *runs for cover*

omg. ok, adopting some F features is an interesting idea. but why are they trying to make that thing with syntax happen?

hehe, I guess they loved CoffeeScript and/or minimalism. But if I want F# features I'd rather use F# and compile to JS with Fable, or simply use ReScript which is more sound than TypeScript any way. If I should learn a new syntax, why not get a better type engine in the process?

Re: Don't use Tailwind for a design system (2021)

#164

Post by redbar0n »

The author's gripe with using Tailwind with components is more concretely expressed in this follow up thread: https://twitter.com/davesnx/status/1329392089189265408?s=20&...

For reference, this is how Tailwind suggests using it with components (aka. "component-driven" as it says, which the author takes issue with): https://tailwindcss.com/#component-driven

I think the gripes come from trying to combine the bottom-up approach of Tailwind with the top-down approach of props based styling that JS component libraries typically allows. His point being that Tailwind does not work too well with such solutions for dynamism / contextual style overrides. You could solve it with using clsx or cva though, as seen in this video:

"Tru Narla: Building a design system in Next.js with Tailwind" https://www.youtube.com/watch?v=T-Zv73yZ_QI

The best way seems to be making styling a completely internal component concern, and not take in style props but simply semantic props like isActive=true and then have the component itself apply styles based on that, like NavItem.js on the Tailwind home page suggests: https://tailwindcss.com/#component-driven

This practise is elaborated in this example, that has the same button styled differently by passing in different semantic props: https://youtu.be/T-Zv73yZ_QI?t=570

Post reply on HN