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

51–60 of 164 posts

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

#51

Post by pcthrowaway »

nwienert wrote: post #45
pcthrowaway wrote: post #27

Earlier quoted context omitted.

I actually agree with this criticism, and it's the best criticism of Tailwind I've seen so far. I still love using it, and will continue to do so. This isn't enough to stop me from using it. Normally I try to avoid this, and abstract the repeated bundle of tailwind classes in a component instead (it can be a container component or just some useful utility component to avoid having to repeat the same group of classes…

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?

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

#52

Post by piaste »

satvikpendem wrote: post #47
piaste wrote: post #35

Earlier quoted context omitted.

As I understand it, Tailwind is essentially CSS 2.0 - or 5.0 I guess - with the warts ironed out (sorry for the unpleasant mixed metaphor): A) CSS / Tailwind: lots of little 'atomic' classes describing individual visual properties. Easy to understand, easy to customize, but slow to read, slow to get started, with plenty of stuff to learn B) CSS frameworks / Tailwind-based components: fewer classes declaratively descr…

CSS is fine, arguably even good these days. For every new feature in CSS, such as the is, has, not selectors, Tailwind needs to reimplement them in its own way, basically becoming a DSL in the process. I mean, look at the syntax for something like this: [--scroll-offset:56px] lg:[--scroll-offset:44px]

Sure, but still, it's the kind of small-but-incremental QoL improvements that apparently frontend designers really really want in their working week.

You linked to a very interesting TS library above, vanilla-extract, and you can probably see that what it does is very similar to what Tailwind does, only plugging into 'tsc' instead of PostCSS? Eg. https://vanilla-extract.style/documentation/styling/#media-q...

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

#53

Post by cutler »

danielvaughn wrote: post #18
jamager wrote: post #16

Earlier quoted context omitted.

Agreed. For me an increasingly important factor is documentation. Good documentation can save so MUCH time and headaches, and tailwind's is so good that I have an easier time accepting its defects and trade-offs on that basis alone.

The tooling around Tailwind is so good. The VSCode intellisense plugin auto-suggests tailwind classes for me, which means I don’t even need to reference the docs unless I’m looking for obscure functionality. It’s amazing.

I've found VS Code's Tailwind intellisense to be unreliable. Half the time it just doesn't generate anything.

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

#54

Post by satvikpendem »

lazy_moderator1 wrote: post #50
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…

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 CSS version of Perl or APL these days.

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

#55

Post by jFriedensreich »

i am thinking about a feature that works like a reverse apply. instead of compiling the tailwind classes into the css class that uses apply, it would add the applied tailwind classes to the html class. this way all the tailwind optimizations and workflows would still work, but at least a few of the problems can be mitigated.

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

#56

Post by satvikpendem »

piaste wrote: post #52
satvikpendem wrote: post #47

Earlier quoted context omitted.

CSS is fine, arguably even good these days. For every new feature in CSS, such as the is, has, not selectors, Tailwind needs to reimplement them in its own way, basically becoming a DSL in the process. I mean, look at the syntax for something like this: [--scroll-offset:56px] lg:[--scroll-offset:44px]

Sure, but still, it's the kind of small-but-incremental QoL improvements that apparently frontend designers really really want in their working week. You linked to a very interesting TS library above, vanilla-extract, and you can probably see that what it does is very similar to what Tailwind does, only plugging into 'tsc' instead of PostCSS? Eg. https://vanilla-extract.style/documentation/styling/#media-q...

It's just using camelCased CSS similar to Emotion or styled-components, how is that similar to Tailwind at all, it's not atomic? Unless you simply mean that both Tailwind and VE have a build step, which is, well, vacuously similar. VE also runs PostCSS underneath after it compiles to CSS, so you can use whatever plug-ins you want too.

Regarding the QoL, it seems more to me that now Tailwind discovered that they have to support arbitrary CSS as well as every new feature, so they have to manipulate their DSL to fit all of that into their current syntax, ie class names, even if it doesn't fully fit. I'd rather just use CSS at that point, if I'm cramming a bunch of stuff into a class name.

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

#57

Post by newbieuser »

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 recommends. you should use everything just as the library intended.

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

#58

Post by simonsarris »

cutler wrote: post #53
danielvaughn wrote: post #18

Earlier quoted context omitted.

The tooling around Tailwind is so good. The VSCode intellisense plugin auto-suggests tailwind classes for me, which means I don’t even need to reference the docs unless I’m looking for obscure functionality. It’s amazing.

I've found VS Code's Tailwind intellisense to be unreliable. Half the time it just doesn't generate anything.

Press Ctrl+spacebar when typing to explicitly invoke it

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

#59

Post by di4na »

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…

The real answer is in CSS developing a proper supported way to do mixins.

I keep being surprised that noone bring this up in these discussions.

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

#60

Post by redbar0n »

sonicgear1 wrote: post #20

Please don't follow the author's opinion. RadixUI with its' 50kB tooltip is not something a sane person would use. This is why React websites weight multiple megabytes at times.

The author recommends ThemeUI, Rebass, Stitches and Radix for design systems, specifically. They might add undue bundle size, to various degrees. Looks like Radix' tooltip is now at 12.77 kB: https://www.radix-ui.com/docs/primitives/components/tooltip

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

It even has a tooltip feature, using floating-ui, which one may or may not add, and seems to come in at around 23 kB (in excess of tamagui core, when overlapping sub-libraries in @floating-ui/react-dom-interactions are discounted)... https://bundlephobia.com/package/@tamagui/tooltip@1.0.5 It's still a bit, but fortunately it's not in core so it's optional to include.

Post reply on HN