[hunterb123]

<td class="p-48 sm:py-32 sm:px-24 text-center">

That's source code from the project. Tailwind is just inline styles via CSS shorthand classes. I cannot understand why anyone would want this unless they are coming from bootstrap.

Tailwind is unreadable when glancing through source code, especially when styles get large. It's just a web fad.

[alunchbox]

It's a different mentally. From tailwinds landing page it explains the reasoning.

A big one is that you don't have to think about abstractions or relationships between classes.

But instead think in terms of utility and really making it a language of it's own right.

I was hesitant but gave it a go. It was quite enjoyable and productive.

There's also the @apply which enabled you to still remove the duplication or build your own utilities on top of their skeleton.

Don't knock it till you try it!

[hunterb123]

I have tried it, but I don't prefer it.

1. Yes it's almost another language, you have to memorize shorthand syntax that is sometimes unintuitive.

2. I need something cross-platform, not a web specific tool. I've moved to RN Stylesheets for both native and web and I don't deal with normal CSS at all.

3. I don't have a problem naming classes, I find it helps maintaining later at the cost of slightly more time upfront. Plus you can compose multiple classes based on states. You can also reuse those classes within the same component. Seems difficult to do that if you inline things. If I did want to skip naming I would use something like JSXStyle/SnackUI instead of Tailwind (direct props, not shorthand strings).

Tailwind is great for web designers wanting to iterate a design quickly, that's about it. I feel you pay for it later though. It's ugly and unreadable at a glance. We just circled back to inline styles.

[steve_adams_86]

> It's just a web fad

It's gaining momentum and it has been around for 4 years (https://adamwathan.me/going-full-time-on-tailwind-css/, https://github.com/tailwindlabs/tailwindcss/commit/421c1b0d7...)

It was preceded by other similar frameworks, too. It's a pattern some people like, and it's productive enough that I suspect it'll stick around.

[hunterb123]

I didn't mean to indicate it would disappear or it's new.

I meant "fad" in the sense that it's really popular right now, but it'll die down later on back to the few that it really clicks with.

I doubt it'll be the standard across the styling ecosystem, it'll be like Svelte, or at best like Vue, is to React.

[steve_adams_86]

Right, I misunderstood you and I agree with that. I suspect CSS might always have some cliquey tools like this because although it's fundamentally not too complicated, it doesn't suit all people's ways of solving problems (visually or otherwise) - they'll always reach for something that helps them abstract it some other way or patch holes in their understanding of the language.

[ookblah]

padding 48, on small screens vertical padding 32 and horizontal padding 24, center styled? try doing that inline....

i always see this and never understand the pushback, or have people never worked on large apps spanning hundreds/thousands of components and have to maintain it.

it's a godsend when working on older components and i don't have to dig thru some other css file and figure out exactly how and why i named it. inline css doesn't allow to do transitions, animations, responsive breakpoints, etc. everything is there is contextual and i never break flow going from design to implementation. you still can have global styles or can have a master design guide.

[hunterb123]

> try doing that inline....

My point was the end result is the same as inline, yes it's less verbose than inline but it's more obscure unless you have all the shorthand class names memorized. It's just a messy string, can you even make that type safe?

> and i don't have to dig thru some other css file

That's a separate issue solved via CSS-in-JS in general. I believe your styles should be isolated to your component, preferably in the same file, not global. That doesn't mean we have to shove styling in the className string attribute.

[likeclockwork]

> My point was the end result is the same as inline, yes it's less verbose than inline but it's more obscure unless you have all the shorthand class names memorized.

It's not the same as inline styles because it expresses things that inline styles fundamentally cannot. Inline styles don't have media queries or selectors.

> It's just a messy string, can you even make that type safe?

WTF? Is any other HTML class string typesafe?

[hunterb123]

> It's not the same as inline styles because it expresses things that inline styles fundamentally cannot. Inline styles don't have media queries or selectors.

Okay, it's as if you added media queries and selectors to inline styles. It's still a nightmare to read like inline styles. It's terse, but as a result it's also more cryptic. It leads to long strings of near gibberish until you carefully read it out.

> WTF? Is any other HTML class string typesafe?

My point is a className string is not typesafe, my styles are fully typed, because it's normal TypeScript. Shoving styles into a string would remove that feature.

I get autocomplete and type checking for the component styles, for example, if it's a view component then it only gets view styles, trying to apply "color" will result in a error.

It's incredibly useful to have autocomplete and type checking for your styles because there are so many combinations of properties. You don't want to supply a number when a string is expected for a font weight, you don't want to supply a value that isn't supported, you don't want to apply a text property that will have no effect on a view element.

Example: https://codesandbox.io/s/dazzling-leaf-rjv7v?file=/src/app/u...