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

91–100 of 164 posts

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

#91

Post by vehemenz »

stefanfisk wrote: post #7
dimitrisnl wrote: post #3

I've been using Tailwind for my component library and I don't agree. For example "It is optimised for writing, but not for reading" is certainly a problem, but this is why I created a component library. To abstract this. Also this is weird: ``` const Card = (props) => { const className = "p-" + props.gap.toString(); return ; }; ``` Why do this? If gap needs to be set, then break apart the Card subcomponents (Card.Tit…

Concatenating Tailwind classes is a huge code smell. While you can safe list them, I've personally never done anything where I felt that it was worth the effort compared to just listing all possible classes.

A good middle ground is to have your linter sort the classnames in a reasonable way. I prefer the “outside in” method. This keeps things readable enough so you can find classes where you expect them.

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

#92

Post by redbar0n »

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

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

#93

Post by rhodysurf »

meet_zaveri wrote: post #13

Started my web dev in bootstrap era. When I found out about tailwind and tried it in one of my side project, I never looked back. In one of my prev companies, I was able convince my engineering manager to use tailwind alongside Antd and it worked flawlessly. Just to make a point here, Antd is an example of design system and I used tailwind as a "utility" from which I can use vast amount of classes without writing sep…

We do the same and haven’t had any problems mixing antd and tailwind

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

#94

Post by naasking »

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…

> At that point, you've just reinvented CSS classes.

Sort of, except instead of context switching between CSS, HTML, JS and your programming language, you can now remove the CSS entirely. Less context switching is good.

I'm a Tailwind fan and I don't see a problem with that pattern for some cases. Obviously there are better ways to organize that should be preferred in general, but it's fine to do that here and there.

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

#95

Post by sergiotapia »

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…

There's an ideal and there's reality. In reality, CSS always ended up spaghetti and horrible to maintain. Even with BEM and other proposed solutions. Human nature and all that.

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

#97

Post by kaba0 »

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 some other page. What can reasonably be shared is variables and a color palette, which you can specify at a single place with tailwind.

But my point, design seems to primarily think in components - so just create a component in your framework/webcomponent, design it locally (e.g. by tailwind) and reuse that widget where you want.

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

#98

Post by Jenk »

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

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

#99

Post by arrow7000 »

naasking wrote: post #94
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…

> At that point, you've just reinvented CSS classes. Sort of, except instead of context switching between CSS, HTML, JS and your programming language, you can now remove the CSS entirely. Less context switching is good. I'm a Tailwind fan and I don't see a problem with that pattern for some cases. Obviously there are better ways to organize that should be preferred in general, but it's fine to do that here and there.

You still have to context switch between thinking about markup vs styling vs behaviour. The language you write the styling in barely makes a difference imo

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

#100

Post by blowski »

abujazar wrote: post #72
blowski wrote: post #36

Earlier quoted context omitted.

In general, framework owners _want_ you to become tightly coupled to the framework, whereas as a user you want to be able to move away from it more easily. I think this conflict of interests is behind recommendations like this, rather than sound technical reasons.

Why would framework owners want you to become tightly coupled to the framework? They're basically just offering a set of solutions that come with some tradeoffs, but they don't intentionally create problems for their users.

For framework owners that have a business built on top of their framework, that tight coupling is their "moat" that helps keep you locked in as a paying customer for longer.
Post reply on HN