[amjnsx]

On conciseness (and possibly scale), isn’t the css “bloat” just being shifted to the html file instead? Has there been sufficient studies in comparing tailwind to say something like:

.MyHeading {color: red; font-weight: bold} // Left container <h1 class=“MyHeading”… // Right container <h1 class=“MyHeading”…

[wildrhythms]

Think about it in terms of components.

// Left container <MyHeading />

// Right container <MyHeading />

What's the point of a .MyHeading class in this instance? Why are you spending so much time naming things solely to reference them in a separate file?

In my Tailwind projects I can have an entire components/ directory with just .jsx files. No more having to spend time naming one-off elements, or cross-referencing class names with separate definitions in separate files.

[nawgz]

> No more having to spend time naming one-off elements

Doesn't this make them untargetable if you ever use it somewhere else? Plus, it already has a CSS name: whatever you named the component (and therefore its folder).

UI code should be modular, component-based, and lends itself to being logically grouped into single folders or files:

MyComponent ->index.tsx ->style.css

Or for vue just MyComponent, etc.

Now, this component has all the abilities that we tap into these frameworks for in the first place: it's composable, it's targetable by a known & unique name, we can use it anywhere without restriction.

I don't even want to imagine a world where I render some component and it has no targetable name... Terrible for reuse

[blindmute]

What do you mean by targetable? The only thing that should be modifying the styles of MyComponent is itself. Any necessary changes should be exposed through the component's public API. Because of this, whether the styles live inside the component itself or in an adjacent css file doesn't matter.

What he means by naming one off elements is that within MyComponent there are multiple native elements that may need to be styled.

[nawgz]

Maybe I don't understand your concept of reuse well, but I certainly don't think all components can just be slapped into the flow of an arbitrary parent container and have the right positioning and styling for free, and if you have to target those off of emergent behavior (i.e. Tailwind classes making it look some way), you are doing something very error-prone.

I also don't think it makes sense to imply the component's creator can know all possible circumstances it will be rendered in and can therefore make an insightful API to control these things. Instead, we can target the fact that CSS is a public API to control styling choices, and expose the classic handle into that API...

[blindmute]

I disagree that you commonly need to style component internals from the outside. But when you do, exposing html class name injection points works fine. By no means should you be writing css to target a component's internals from outside of the component's own css file. That leads to a mess and is the opposite of reusable. The HTML structure of a component is private.

[nawgz]

> I disagree that you commonly need to style component internals from the outside

Can you say more? For example, if any use case for it exists - which you seem to agree - surely you can see anyone inside such a use case would prefer to have this for free.

For example, I built a nice declarative form using React. I reuse my own Input fields and such. To control their spacing, I target their classNames for some occasions, like "MyLibraryInput" etc.. To be clear, this className belongs to the top level parent of that HTML structure and no styles of the type I described interact with the private HTML of that component, which I am surprised I have to state given that you are responding to a comment stating "I certainly don't think all components can just be slapped into the flow of an arbitrary parent container and have the right positioning and styling for free" and "we can target the fact that CSS is a public API" for single elements because that's quite exactly what it is...

> exposing html class name injection points works fine

So, after all this about how this use case is invalid, you just argue that someone who needs to do this type of thing should have to make extra wiring for no reason? I mean, certainly it functions, but it's a completely unnecessary step to force consumers to go thru. I do not understand this perspective at all.

[yurishimo]

A point that is not immediately front of mind in these discussions is that Gzip/brotli makes these comparisons moot. Similar strings will be referenced with a pointer and take basically zero extra bits down the wire. That's one place where tailwind get's a huge boost. It's a ton of repetitive code that compresses extremely well.

If you use a plugin to sort your class names like Headwind[0] then it can be optimized even further.

0: https://marketplace.visualstudio.com/items?itemName=heybourn...