5 ms·
> 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 ha
by the_other 4y ago
> 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.
- andiareso 4y agoBut 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
- deleted 4y ago[deleted]
- LouisSayers 4y agoAnd what about your :hover, ::before etc, where do you put those? (genuinely curious)
- timdorr 4y agoThose have utility classes: https://tailwindcss.com/docs/hover-focus-and-other-states https://tailwindcss.com/docs/hover-focus-and-other-states
- seek 4y agoTailwind supports those https://tailwindcss.com/docs/hover-focus-and-other-states#hover-focus-and-active https://tailwindcss.com/docs/hover-focus-and-other-states#ho... https://tailwindcss.com/docs/hover-focus-and-other-states#before-and-after https://tailwindcss.com/docs/hover-focus-and-other-states#be...
- meowtimemania 4y agoOne 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
- xigoi 4y agoThe difference is that your website will be much larger and won't work without JavaScript.
- 1shooner 4y ago> 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.
- ramesh31 4y agoCascading 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.
- deergomoo 4y agoThis 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.
- the_other 4y ago> 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.
- 4y ago
- ryanf 4y agoWe 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.
- jsf01 4y agoIf 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.)