Comment by the_other | Hacker News Reader

Comment by the_other | Hacker News Reader

Parent Full thread

> If you're not using Tailwind (or something like it) then you're going to end up creating classes using the raw CSS, and then naming them yourself, and then having to remember what you called them.

This is true. But if we better taught the cascade and promoted the idea of global styles rather than pretending it's a problem then more people would be better at this and the problems would gently recede.

We (the high-end front-end dev community) have fallen into the habit of using class names where we really wanted IDs and using components when we really wanted global styles. I feel we have been pushed in this direction by developers who didn't understand the technology properly. The Tailwind author clearly understands it, so I'm not targeting them... but they are supporting the people who don't see why the cascade is useful.

We have megabytes of code to create the impression of global consistency (components, style libraries, CSS-modules...) shipped to millions of users every hour. Browsers do that for us already. Embrace the simplicity of

button { border: foo; color: bar; } .callout button { color: aux; }

It's so clear, so elegant. The obsession with modularising everything, and then applying a DSL to get between the modules, makes the language's inherent convenience, elegance and clarity so much harder to work with that it boggles my mind.

> It's so clear, so elegant.

The thesis of Tailwind is that the cascade actually becomes very unclear and inelegant at scale, and I would say the reason it's so popular is that many devs share that experience.

Cascading is excellent for websites. Terrible for applications. There's no concept of anything even remotely similar in any other UI technology. Native applications have use the "scoped component" paradigm for decades, and the web is finally catching up.

This is the crux of it really. It makes a whole lot of sense to have cascading styles in documents. I don’t want to have to explicitly set a text colour for each individual paragraph.

But the opposite is largely true for UI elements. For one, I’m probably using some external templating or component framework to repeat them, because they mostly likely have behaviour attached and HTML by itself has no good story for that. For two, I pretty much never want their styling to be modified by the context in which they’re used.

> This is the crux of it really. It makes a whole lot of sense to have cascading styles in documents. I don’t want to have to explicitly set a text colour for each individual paragraph.

But that’s what you’re doing when you use scoped styles, components, Tailwind etc.

Just set it once, on body and forget about it for the lifetime of your app.

> I pretty much never want their styling to be modified by the context in which they’re used.

I guess we have worked on different projects. To me this sounds like the edge case. Most projects I’ve worked on want all the components/widgets/thingies in one consistent style that works together for a cohesive overall experience. For such situations (which to me feel like the majority case) the cascade is the simplest tool.

>Most projects I’ve worked on want all the components/widgets/thingies in one consistent style that works together for a cohesive overall experience. For such situations (which to me feel like the majority case) the cascade is the simplest tool.

This is the distinction to me. New methods in composing a page approach this differently: style consistency is maintained through dependencies and a build process rather than relying on context. To understand the styling I'm applying to a given HTML elemnt, I can look to the packages going into the build (just as a I do with other aspects of the code) rather than needing to understand every context my component could possibly be invoked within.

We collectively tried the approach you’re describing, and we stopped doing it because it sucks. It looks nice in simple cases, but the lack of encapsulation or locality makes it impossible to change upstream styles without breaking something somewhere else. Also you have to use horrible BEM-style names to avoid accidental collisions between styles from different parts of your app, which kind of ruins the elegance in itself.

If your projects are small enough that relying on the cascade is a reliable option, you probably don’t need tailwindcss. If you’re working with 50+ devs on the same code base with many moving parts and shared components, you can’t afford to verify whether the cascade breaks something on every single change. So imo there’s nothing inherently wrong with your post, it’s just that tailwindcss doesn’t really excel until you’re working with a bunch of people authoring css in a shared codebase. (That said, now that I’ve drunk the kool aid I use tailwind or windi css even on my own projects. It’s pretty great once you know it.)

But this isn't much different than:

<Button class=`border text-gray ${override}`/>

<CalloutButton /> extends <Button override="text-blue" />

I'd argue you have less markup to write overall if you are modularizing component logic/styling

One gripe I have with tailwind, is overriding styles is difficult. The .text-blue style will only override .text-gray if it is declared later in the css document.

for example if the corresponding css file is this: .text-blue { color: blue; } .text-gray { color: gray; }

Then in your above example, both Button and CalloutButton will have gray text because .test-gray has higher specificity than .text-blue

The difference is that your website will be much larger and won't work without JavaScript.

And what about your :hover, ::before etc, where do you put those? (genuinely curious)

Those have utility classes: https://tailwindcss.com/docs/hover-focus-and-other-states

Tailwind supports those

https://tailwindcss.com/docs/hover-focus-and-other-states#ho...

https://tailwindcss.com/docs/hover-focus-and-other-states#be...

Reply on news.ycombinator.com