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

131–140 of 164 posts

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

#131

Post by nobleach »

zmxz wrote: post #80
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…

Out of curiosity, have you used Tailwind and does your criticism come from having used it and not experiencing the progress or does your criticism come from reading how it works and not "feeling" it? I don't intend to follow up with discussion that convinces/dissuades/criticizes you in any way, I just ask purely out of curiosity.

I'm not the one you're asking but, I messed around with it a bit and it really left a bad taste in my mouth. There is just much hype behind it though, so I bought the book to really get a feel for it. I liked the book. I used it in a project and after going back to code written by a few members of the team, it just felt like an unmaintainable mess. The common response whenever I share this sentiment is one of:

* You don't know what you're doing * You're doing it wrong * You're an idiot.

It really kinda feels like the old AngularJS 1.x days as those were the typical responses to anyone who didn't fall down and worship it as a framework masterpiece. I've decided for myself, I'll sit this one out. Judging by history, most of the things we were fanatical about at first, we tend to look at with disdain in a few short years. jQuery, AngularJS, Bootstrap, Redux... It would be foolish to think this library/framework won't go the same way.

If you use it, and it works for you and your team, that's great. I would never try to tell you NOT to. For me, I'd rather not.

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

#133

Post by manxman »

kaba0 wrote: post #97
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…

The underlying purpose for the “cascading” was customizing the look of documents by the user. We seldom have truly static web documents any more and this use case is non-existent even for those. In my experience cascading is simply not a great idea even in itself — you can’t reasonably share part of your design between different components, it causes way too close coupling, breaking some non-intended component on som…

I don’t think it’s about “documents” versus “components”. It’s about consistency and maintainability.

Keep the local styling for the component local to its place in your repository - absolutely. Give it sensible defaults - for sure. But if you’re using it in something complex where the overall design may evolve it’s a maintainability nightmare to hardcode the styling at the component level and/or designing by classname.

I get why initial development is faster BUT… if you want to make a simple style change on a 100 component site - do you really want to be editing a load of components for every change down the line?

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

#134

Post by manxman »

zmxz wrote: post #80
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…

Out of curiosity, have you used Tailwind and does your criticism come from having used it and not experiencing the progress or does your criticism come from reading how it works and not "feeling" it? I don't intend to follow up with discussion that convinces/dissuades/criticizes you in any way, I just ask purely out of curiosity.

Yea I’ve used and I think it’s cool for prototyping quickly but the idea of coming back and making edits to it in production code a year from now terrifies the bejeezus out of me.

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

#135

Post by adamscybot »

franky47 wrote: post #106
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 do write like that. Heck, even a mix of both: , using Chakra-UI [1] (not too dissimilar to Tailwind in spirit). Even the best design system needs local overrides to satisfy a product owner's incomprehensible requests, like "can we push that button a few pixels to the left?". [1] https://chakra-ui.com/

Right, huge +1 for Chakra. Chakra is basically tailwind but built on react primitives. It feels lot cleaner, and solves most of the issues mentioned.

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

#136

Post by kaba0 »

manxman wrote: post #134
zmxz wrote: post #80

Earlier quoted context omitted.

Out of curiosity, have you used Tailwind and does your criticism come from having used it and not experiencing the progress or does your criticism come from reading how it works and not "feeling" it? I don't intend to follow up with discussion that convinces/dissuades/criticizes you in any way, I just ask purely out of curiosity.

Yea I’ve used and I think it’s cool for prototyping quickly but the idea of coming back and making edits to it in production code a year from now terrifies the bejeezus out of me.

If you apply it to a component that you reuse then how is it unmaintainable?

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

#137

Post by manxman »

sodapopcan wrote: post #129
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.

I agree it has a place for rapidly prototyping a design. But it pukes in the face of the “DRY” principle and wouldn’t keep it around in production. Use it to get the look right, take the styles and abstract to a sensible place in the design system or component hierarchy passing in the values so you can change one thing not a load.

Just following the idea that making life easier for yourself six months from now when you don’t have the current project “context” in your head is way better for lowering technical debt.

Oh and we will probably be into another fashionable styling framework by then! ;-P

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

#139

Post by sodapopcan »

manxman wrote: post #137
sodapopcan wrote: post #129

Earlier quoted context omitted.

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.

I agree it has a place for rapidly prototyping a design. But it pukes in the face of the “DRY” principle and wouldn’t keep it around in production. Use it to get the look right, take the styles and abstract to a sensible place in the design system or component hierarchy passing in the values so you can change one thing not a load. Just following the idea that making life easier for yourself six months from now when y…

It's been explained in many blog posts as well as in the Tailwind documentation itself. It's meant to be used with components (or partials). There's no copy-pasting involved and is very well-suited for production code.

And this applies to any utility-based CSS framework.

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

#140

Post by franky47 »

adamscybot wrote: post #135
franky47 wrote: post #106

Earlier quoted context omitted.

I do write like that. Heck, even a mix of both: , using Chakra-UI [1] (not too dissimilar to Tailwind in spirit). Even the best design system needs local overrides to satisfy a product owner's incomprehensible requests, like "can we push that button a few pixels to the left?". [1] https://chakra-ui.com/

Right, huge +1 for Chakra. Chakra is basically tailwind but built on react primitives. It feels lot cleaner, and solves most of the issues mentioned.

It's amazing for quick UI building.

Note however that this API is brought by Styled System [1], which Chakra uses (and exposes), and adds the component library and other niceties on top.

My only regret with Chakra is that it's a tad runtime-heavy, and it's not really adapted to static content. I'd love to see some sort of compiler that digests a React tree into rendered HTML + CSS, with minimal JS just for style interactions (is this what Svelte does?)

[1] https://styled-system.com/

Post reply on HN