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

61–70 of 164 posts

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

#61

Post by TeMPOraL »

satvikpendem wrote: post #54
lazy_moderator1 wrote: post #50

Earlier quoted context omitted.

all kinds of companies make bad choices, i've also seen a bunch of companies use tailwind correctly -> components + @apply are enough to make it very pleasant to work with :)

While that may be true, as I mentioned, if many companies repeatedly keep making the same errors (including a sibling commenter here), it is on the creator to fix it, not the user, and even if they do, it could be a bad solution. Personally I've moved off of Tailwind entirely, too many footguns to deal with, and I'm not sure why it's any better than writing CSS, at scale, not prototyping. In a way, it feels like the…

> In a way, it feels like the CSS version of Perl or APL these days.

Perl, maybe, but not APL. CSS version of APL would let me style my personal site and blog in less characters than it took me to write this comment :).

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

#62

Post by nwienert »

pcthrowaway wrote: post #51
nwienert wrote: post #45

Earlier quoted context omitted.

Tamagui really aims to solve this problem and some of the usability problems of className by putting style props directly on the props. You can nest components and abstract them as you want and still get the Tailwind style shorthands except as TS typed tokens. No worry about how you reference things or static-ness etc and the final output can be flattened down to just div + css even across module boundaries or when n…

Interesting.. so is Tamagui using react under the hood, but "hiding" it from you to some extent? Does it provide some helpers for responsiveness?

It’s just React through and through. It has an optional optimizing compiler that really improves performance even across hard to parse areas like nested conditional logic or spreads of items across module boundaries.

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

#63

Post by redbar0n »

newbieuser wrote: post #57

tailwind is a library I don't like in many ways, but the criticisms in this post are pretty ridiculous. tailwind is not a library offered with the motto of component driven as the author mentioned. and instead of bloated packages like radix ui I think it's a more sensible solution. at least it gives a chance to follow a more optimal path. I think it is impossible to find an optimal way with the libraries it recommend…

> tailwind is not a library offered with the motto of component driven as the author mentioned.

I thought Tailwind shined the most when used within components (and why it's become so popular with React).. making components and not CSS the nexus of abstraction.

> and instead of bloated packages like radix ui I think it's a more sensible solution. ... I think it is impossible to find an optimal way with the libraries it recommends.

The author recommends ThemeUI, Rebass, Stitches and/or Radix for design systems. They might add undue bundle size, to various degrees.

But a recent and very powerful (close to as optimal as possible?) alternative is Tamagui which takes inspiration from all of those. All for the cost of some 20-27 kB, apparently with a clear path to come below 8 kB in the future: https://tamagui.dev/blog/version-one#bundle-size-reduction

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

#64

Post by balfirevic »

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…

  > const headerClasses = [(list of Tailwind classes here)];
  > ...
Why wouldn't they extract the header as a higher-order component? That would make more sense even without Tailwind, and I haven't heard anyone in the Tailwind community advocate against that.

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

#65

Post by tekkk »

simonhamp wrote: post #33
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…

I believe the solution here is most definitely @apply. I know the Tailwind team seem to be against @apply (and even flirted with removing it), but having used it extensively to build complex (imo) sites and apps, @apply has been unavoidable and actually great to have. The fact is @apply is there and if we're using it and there's enough push-back, I don't see why the Tailwind team wouldn't listen to that or create a w…

Yeah I don't understand what the other solution would be. If you want to have reusable styles, eg "btn" class with all your defaults @apply is the obvious choice. Otherwise you'll end up with similar gargantuan CSS class spagetti and/or have to abstract away some generic components because handling the classes is just too much.

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

#66

Post by have_faith »

balfirevic wrote: post #64
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…

> const headerClasses = [(list of Tailwind classes here)]; > ... Why wouldn't they extract the header as a higher-order component? That would make more sense even without Tailwind, and I haven't heard anyone in the Tailwind community advocate against that.

I think this is just an example but `header` is a standard HTML element. It's not always necassary to seperate every single element into it's own component. Every time you make a framework component you add overhead to the rendering of the app.

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

#67

Post by replygirl »

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…

windicss is a superset of tailwind that lets you define shortcuts and aliases for easier composition, and variant grouping for less typing

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

#68

Post by manxman »

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 about making it easy to “pixel f*k” your way to getting the design you want in one given place at the expense of having consistency and maintainability.

E.g. with a proper CSS template I can ensure all fonts and sizes and colors are consistent across an app. With Tailwind everything starts to be like the 1990s where all your design was hard coded into table and font elements mixed into your markup!

This does NOT seem like progress!

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

#69

Post by replygirl »

have_faith wrote: post #66
balfirevic wrote: post #64

Earlier quoted context omitted.

> const headerClasses = [(list of Tailwind classes here)]; > ... Why wouldn't they extract the header as a higher-order component? That would make more sense even without Tailwind, and I haven't heard anyone in the Tailwind community advocate against that.

I think this is just an example but `header` is a standard HTML element. It's not always necassary to seperate every single element into it's own component. Every time you make a framework component you add overhead to the rendering of the app.

> Every time you make a framework component you add overhead to the rendering of the app.

not true, separating components by concern can save you a lot of fiddling with memoization

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

#70

Post by balfirevic »

have_faith wrote: post #66
balfirevic wrote: post #64

Earlier quoted context omitted.

> const headerClasses = [(list of Tailwind classes here)]; > ... Why wouldn't they extract the header as a higher-order component? That would make more sense even without Tailwind, and I haven't heard anyone in the Tailwind community advocate against that.

I think this is just an example but `header` is a standard HTML element. It's not always necassary to seperate every single element into it's own component. Every time you make a framework component you add overhead to the rendering of the app.

> It's not always necassary to seperate every single element into it's own component.

It's not necessary but in the given case it's obviously useful as there is more to abstract than just the html element - the styling.

Post reply on HN