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

121–130 of 164 posts

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

#121

Post by redbar0n »

lyxsus wrote: post #83
manxman wrote: post #68

Is it just me or has the underlying purpose and value of “cascading” in CSS been lost within these abstractions. The only real limitations with CSS imho was just lack of variable support for easily passing in variables to set color schemes and/or dimensions etc. These seemed to be readily fixed with SCSS and the various options for embedding CSS in JS using styled components and the like. Tailwind seems to be all abo…

tbh, tailwind feels like the worst thing that happened to frontend dev since coffee script.

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

*runs for cover*

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

#122

Post by redbar0n »

caseyf wrote: post #73
manxman wrote: post #68

Is it just me or has the underlying purpose and value of “cascading” in CSS been lost within these abstractions. The only real limitations with CSS imho was just lack of variable support for easily passing in variables to set color schemes and/or dimensions etc. These seemed to be readily fixed with SCSS and the various options for embedding CSS in JS using styled components and the like. Tailwind seems to be all abo…

I find that using utilities where appropriate is a win, not everything need be extracted into a stylesheet or component. Having a standard library of utilities makes sense because if you don't use one you end up writing the exact same thin since they are mostly one liners. What I don't understand is why you'd want to build a design system component out of utilities much less build everything out of utilities.

Here's an example that might give an idea: https://tailwindcss.com/#component-driven

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

#123

Post by redbar0n »

hakanderyal wrote: post #116

I'm going the opposite way and switching from CSS-in-JS to Tailwind. While I like the css-in-js way of doing things, React seems to be moving away from runtime css generation, and I'm not sure the ecosystem will catch up (and I'm tired of playing catch up). Sticking to CSS guarantees you won't have any compatibility problems.

> Sticking to CSS guarantees you won't have any compatibility problems.

Unless you attempt to go cross-platform.. There are many attempts at getting CSS working on React Native for instance, and many have various compatibility problems (especially as they need to keep up with the evolving CSS spec).

But if you do go cross-platform, then something like Tamagui is probably a better bet than trying to replicate CSS. You could also try Nativewind, to get the Tailwind benefits (and limitations, like lack of support for animations).

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

#124

Post by brnewd »

I'm still firmly in the Bootstrap camp. It's boring, well understood by the average website visitor. Allows for rapid development and thereby time to market. I tried Tailwind once, but found the added complexity not worth the trouble. I guess it all hinges on the type of project(s) and runway.

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

#126

Post by thinkxl »

This is how we do it.

We don't use Tailwind directly on your components (unless necessary and for adjustment only, more on this later).

We try to keep Tailwind as an internal implementation detail. The consumer of our components should pass options as `variant="primary"` where `variant: "primary" | "secondary";` BUT it's okay to allow some Tailwind classes for customization on edge cases.

Example (by memory, syntax might be wrong):

  import cn from 'classnames';

  // Definition
  function Button({ fill, isLoading, className }: ButtonProps) {
    return (
      {children}
    
  );

  // Usage

  // Full-width button, with some margin on the left
  

  // Regular button, with loading state
You can even go further and use https://github.com/crswll/clb and create your own rebassjs.

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

#127

Post by [deleted] »

Jenk wrote: post #98
dubcanada wrote: post #84

This should be called "Don't use Tailwind in a React library for a design system" as this really has nothing to do with Tailwind and is all about integration of Tailwind into a React design system. None of these "negatives" are "negatives" for using it as part of a standard HTML/CSS website outside of React. The comparison between readability of a bunch of divs and web components or react makes no sense, of course is…

I'm guilty of implementing as export { SideBarItem = ( ) } Is that a bad thing? (Genuinely asking for opinions) E: added clarity

[deleted]

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

#128

Post by noselasd »

redbar0n wrote: post #92
esskay wrote: post #22

Tailwind isn't component-driven, which they claim to be Stopped reading there. It's a utility library, that much has always been blatently clear and obvious. Really poor article.

I also found this section on the TailwindCSS landing page...: > Component-driven: Worried about duplication? Don’t be. ... https://tailwindcss.com/#component-driven

The way i read that is that "if you are using Tailwind in a component based framework, do e.g. this ...".

Which is entirely different thing than saying "Tailwind is component driven".

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

#129

Post by sodapopcan »

manxman wrote: post #68

Is it just me or has the underlying purpose and value of “cascading” in CSS been lost within these abstractions. The only real limitations with CSS imho was just lack of variable support for easily passing in variables to set color schemes and/or dimensions etc. These seemed to be readily fixed with SCSS and the various options for embedding CSS in JS using styled components and the like. Tailwind seems to be all abo…

This is the same repeated criticism that gets repeated over and over and over again about Tailwind. It's misguided and getting a bit tiresome.

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

#130

Post by hakanderyal »

redbar0n wrote: post #123
hakanderyal wrote: post #116

I'm going the opposite way and switching from CSS-in-JS to Tailwind. While I like the css-in-js way of doing things, React seems to be moving away from runtime css generation, and I'm not sure the ecosystem will catch up (and I'm tired of playing catch up). Sticking to CSS guarantees you won't have any compatibility problems.

> Sticking to CSS guarantees you won't have any compatibility problems. Unless you attempt to go cross-platform.. There are many attempts at getting CSS working on React Native for instance, and many have various compatibility problems (especially as they need to keep up with the evolving CSS spec). But if you do go cross-platform, then something like Tamagui is probably a better bet than trying to replicate CSS. You…

I don't need native and web compatibility, so no problems on that front.

Tamagui is on my radar, but it's too new for me to give it a try with my limited time budget.

Post reply on HN