Hacker News Reader

Comment by krvajal | Hacker News Reader

Tailwind v20 = just css

The spec authors should be looking at the popularity of Tailwind and be thinking of how to enhance the style attribute. Then Tailwind really could mostly be a bunch of CSS variables and inline styles.

Tailwind depends on @apply in PostCSS to function, something that was never officially proposed for CSS, but has been killed by its author and we know for sure CSS won't do, for the reasons the author of the original @apply idea lists here: https://www.xanthir.com/b4o00

So we have known all along that this will never happen. It was rejected for some very good reasons before Tailwind began.

I've been working on a library that is basically what you're describing: https://github.com/nealfwilliams/style-kit-n

Feedback welcome

an argument for it is that it couples content and styling together, instead of them being in different layers.

Sometimes, they are, and should be, separate. But in other cases, styling is related to the content, or part of it.

The only time I can imagine coupling content and styling together is if you have mostly non-repetitive elements in the content (rare, I think, maybe some very "designed" landing page, or whatnot), or you have other ways to repeat the elements without writing the styles out each time for each element. (And at that point you've just moved the problem of having to invent names for CSS classes to having to invent names for bunch of "components" and their properties)

Any UI beyond trivial lists will couple style and content.

You have a card? Boom, you need to couple styles for the title, for the content, for the footer etc.

You have a form? Boom, you need to couple styles with the form.

The idea that styles are somehow decoupled from content is funny idea that very rarely works out in practice.

You missed the point.

Would you copy paste around:

20x around your static website and keep it updated manually when someone "from design" wants to change the "form" look?

Or would you just <form class="classic-form"> and describe the style of that class of form in a single place?

I know what I'd do. :)

This is achievable in a much nicer way with SFC frameworks like Vue and Svelte where you also get scoped styles and other benefits. One of the reasons Tailwind is so popular is that so few developers know anything other than React.

Tailwind works just as well in Svelte and Vue

Of course it's just class names, what I mean is that if fewer people used React and more used Svelte/Vue they would feel less need for things like Tailwind or CSS-in-JS.

My argument is that React is actively bad for writing HTML/CSS, and therefore people came up with clunky solutions to get around those limitations. Certainly Tailwind is more than just a solution for React, but a large part of its popularity is due to it.

> they would feel less need for things like Tailwind or CSS-in-JS.

Why do people keep mentioning Tailwind and CSS-in-JS in the same sentence?

And no, Tailwind would still have its place even if Svelte appeared first because instead of writing the same styles everywhere you'd still want to extract them into a file, and have sensible defaults for them.

Oh look, Tailwind does exactly that.

> Why do people keep mentioning Tailwind and CSS-in-JS in the same sentence?

Because one of the biggest arguments for each is scoping styles to a component instead of the default global cascade.

> And no, Tailwind would still have its place even if Svelte appeared first because instead of writing the same styles everywhere you'd still want to extract them into a file, and have sensible defaults for them.

Writing same styles everywhere? I'm not sure I understand what you mean, that isn't related to Tailwind or frameworks. Sensible defaults are just design system tokens, those are usable in way more styling approaches than just Tailwind.

I'm not saying Tailwind wouldn't exist, I'm saying it wouldn't be as wildly popular as it is now. React's lack of CSS features has encouraged a generation of frontend devs to simply not learn CSS fully. Sure you need to know some CSS to use Tailwind, but in many cases people just copy-paste Tailwind templates from elsewhere (another benefit of Tailwind) and don't actually understand the styling. I see Tailwind classes that do nothing in the wild all the time.

> Because one of the biggest arguments for each is scoping styles to a component instead of the default global cascade.

Escaping the global cascade has been on everyone's mind since forever. BEM, one of the lost popular ways to try and scope CSS to components, was invented in 2006: https://en.bem.info/methodology/history/

OOCSS is 2009: https://www.slideshare.net/stubbornella/object-oriented-css

> Writing same styles everywhere? I'm not sure I understand what you mean,

You need to specify things like font sizes, line heights, border styles, colors etc.

> React's lack of CSS features has encouraged a generation of frontend devs to simply not learn CSS fully.

This has nothing to do with React. No one ever learned CSS fully. If anything, Tailwind encourages you to learn more CSS.

> but in many cases people just copy-paste Tailwind templates from elsewhere (another benefit of Tailwind) and don't actually understand the styling.

How different is it from all the history of the web?

Reply on news.ycombinator.com