Moving away from Tailwind, and learning to structure my CSS

> inline CSS can't be cached

this shows your lack of understanding. first off, it's not inline css, they're classes and thus you only ever define "flex" in one place vs many many places in non-utility css approaches. in fact, sorted html classes are compressible over the wire so you're doubly wrong.

> because they never learned it properly condescending

> it lets you use CSS while not requiring an understanding of how CSS works, beyond its most basic concepts also condescending and just such a boring, over used argument i always hear from haters of tailwind maybe try and counter my arguments without the attitude? maybe understand seasoned veterans of css might have their reasons to choose it?

Sure it’s not as dry, but I’ve been bitten in this regard because css framework and templates are so intransparent, preventing me from simply changing padding or margin.

CSS is too detailed and too verbose. Frameworks like bootstrap are too high level and don’t give enough control. Tailwind hits the sweet spot whilst allowing me to be detailed if I want to. It allows me to just get it done.

Can vanilla CSS be used for a complex app? Yes. But, it takes discipline, and I only have a limited amount of that. I’d rather spend my discipline budget on other things.

That said, nested selectors and CSS variables have gone a long way towards making the vanilla experience much more pleasant. I may have to give it a shot on a side project one of these days.

If CSS had nesting, variables, media queries, the other nice selector queries like :has, and modules out of the gate, we likely would have not needed much of the tooling like tailwind that eventually got built to manage it all with less boilerplate. We built the tools because even when these features rolled out they came in fits and starts so you couldn’t adopt it without polyfills and whatnot.

Can you elaborate what the problem is? What is it you want to cache?

> and it creates a lot of noise when using dev tools for debugging.

I don’t think so. The element styles have an own section (assuming you debug the applied styles)

> It actually increases cognitive load because you have to account for CSS in two different locations.

Same applies to no tailwind. You need to account for the html (is parent block / inline / …) anyway.

Also, DRY can still be somewhat achieved with tailwind by using reusable components, in whatever framework you're using. It could be React, but it could even be blade components in a traditional SSR Laravel app.

Many times it's fine to repeat yourself. Many times it's fine for a component to cross multiple concerns.

[1]: https://every-layout.dev

How does doing everything in-line (one place) cause two locations?

Thanks.

Classes are now in-line styling? Why are you doubling down on a subject you're obviously not familiar with?

And the separation of concerns argument is always strange to me because in React, my concern is the component.

Please show me only ten of the SaaS you lead that rely on your CSS framework.

You must have one, because you talk about structure and premises. Orderly put and repeatedly applied you get a framework.

I doubt it.

I registered my first domain 1997. I love to debate anyone coming up with a clever not so clever theoretical argument against Tailwind.

Where are all the you might not need jQuery JavaScript guys?

The same goes for Tailwind.

And just as a reminder: CSS started as so called separation of markup and design. A zen garden tried to proof this but only showed how one cannot exist without the other.

Loose coupling as the saying goes.

Since the ACID test CSS went from some proposals to a stunning black hole of finally receiving differential treatment with the level nomenclature.

And you besides all incompatibility issues and different browsers still think that you really grasp CSS or even know how to apply it semantically correct even though by matter of fact many concepts feature bogus terminology due to compatibility issues?

I would love to interview you regarding edge cases. Do you get box models? Collapsing markings? Floats? Clearfix? Order of application?

Print layouts? Views vs fluid design?

Really, attacking Tailwind is the same as “Let’s build our own Google” trope. It shows lack of competence.

In my mind it’s the best of both worlds. Vue makes it easy. I think CSS modules in React work similarly

But this isn't a unique flaw for Tailwind. I've been coding with CSS since the late '90s and seen plenty of people throw yet-another-div onto the DOM just to have an element to hang their classes on. Done so myself plenty of times, too.

People have been complaining about div soup for years and years before Tailwind ever came along.

Plus I'm coding with Tailwind now, and almost never think about my classes before my HTML. Nothing about Tailwind in particular encourages you to do so. So I'm quite confused how this is a unique Tailwind flaw.

> If you have some unique feature to tailwind that you think makes it better than the rest, you should share that.

i did mention some but you'll then claim it's not unique because some other tool has it so...

> Everything you have listed is also accomplished by all the other CSS frameworks

not true. most frameworks for example do not have nearly the universal familiarity tailwind has, for example. tailwind has a build tool that strips unused selectors and can dynamically build new classes (eg "w-[20rem]") if needed. do all frameworks do that? maybe a few but most do not

> sounds like tailwind is simply the main one you have experience with.

i've used so many frameworks i cannot count them on my hands (and feet even). i've settled on tailwind because it solves problems better than any other tool i've used. that's my preference yes, but your implication that i'm just using it because it's the only thing i know is so far from the truth it's comical

do yourself a favor and stop assuming people choosing tailwind don't know what they're doing

> If you need extra elements for styling at that point, you might use a div or span (but you should ask yourself if there's something better first).

This is IMO not worse than vanilla CSS, and it's simply the only way to have customizable layouting in HTML.

But if you have to use `display: flex" in a lot of places, having the `flex` utility is better. And there are tons of such utilities with Tailwind.

you read a lot into me choosing "application" instead of using "website". for the record i think tailwind works great for both and it actively using in in a many tens of thousands of LOC web "application" and managing a team using it on a fortune 100 mostly static website that gets millions of views a month.

tailwind works great for both and in fact i'd argue works even better on "static" sites because it's efficient bundles and selector compression over the wire. we don't ship a single byte of css we don't use, thus saving on wasted bandwidth and increasing our SEO/page speeds

> There is no need for frameworks. Well structured and scoped CSS can handle it all.

i love when people are so confident other people don't have valid reasons to use tools. real "junior dev" vibes, my friend

> What if not that does CSS already offer? I don't see how normal CSS does not already do that. No additional thingamabob needed.

how many "bespoke" css projects have you worked on? i've works on MANY. nearly all of them suck to get familiar with and to not risk messing up some weird selector hierarchy you weren't aware of. can it be done well? sure, but it's incredibly rare and often only happens on smaller teams/projects. scaling out bespoke css sites becomes increasingly challenging as you scale in LoC and team size.

on the other hand, give me any tailwind project and i can start contributing immediately

> Tons of ready-made stylesheets out there to use for teams. What more of an "ecosystem" do I need to style a web page? Why do I need an ecosystem? Is it not rather a tailwind self-induced need?

ready-made stylesheets? do you mean like a css/html template?

the ecosystem means IDEs work well with it, there are lots of help resources, llms are trained on them heavily, you can find devs who know how to be productive with it, etc.

you can be very familiar with css but struggle within some bespoke framework with the fact that you can structure css in near infinite ways. tailwind gives you a consistent structure and approach across projects

That's never been a valid argument to dismiss criticism. It wasn't with Dreamweaver, any it wasn't with visual basic, and it isn't with Tailwind.

Patterns matter. Best practices matter. Path of least resistance matters. Those are all choices you make when you develop a CSS framework. Some of those choices are good and some are bad.

If none of those things mattered, them choosing a CSS framework would not matter at all.

They fixed this later with Fragments but the damage was done.

Not sure if it helps, but if we get our first blind user I will gladly make some admends to make it more usable for them.

It seems that Tailwind is now blamed for the mess that is HTML/CSS. Tailwind certainly allows for accessible designs; it may not be the ideal solution, sure, but what we aim for is "good enough".

I feel like old-school frontend devs bring up accessibility as a kind of bogeyman.

It reminds me of the myth that CSS style X or Y breaks accessibility "because screen readers expect semantic CSS classes". Zeldman (of A List Apart) promulgated that disinformation for years, until someone actually told him screen readers don't work that way. 90% of people who use a11y as a rhetorical cudgel have never actually used AT themselves.

Disability software that uses both the markup and the on-screen visual for decision making is likely imminent and would render most of this no longer necessary.

Claude Cowork is already doing navigation and web browsing by screenshot showing this is possible.

The conversations here regarding UX? (Acting like it’s black magic, not basic empathy?)

The exact same disconnection exists between dev and abled users.

Like many new-ish CSS features, adoption is low; around 4-5% from a crawl of 17 million sites [1]. It's been available in all major browsers since 2022.

I'm generally addressing developers who are never going to use any (or very little) modern CSS [2]. There was a thread on HN where some participants complained about "all these newfangled CSS features". Several didn't see the need to learn CSS Grid, even though it's been available for nearly 10 years. (Aside: I really disliked the floats/tables-for-layouts era, with the requisite IE hacks.)

There are lots of developers who don't see a need to use features they weren't using in the late '90s or early 2000s. For a lot of them, they'd rather use the devil they know.

There’s a huge gap between web developers who speak at web conferences, appear on CSS-themed podcasts, and who are members of standards bodies vs the 9-5 developer that works for some insurance company or school, who's not a CSS enthusiast or hobbyist. Using ITCSS would be awesome them.

Finally, there's nothing unreliable or non-native about ITCSS; it's just CSS where the layers are in specificity order. It doesn't get any more native than that.

[1]: https://almanac.httparchive.org/en/2022/css

[2]: https://modern-css.com

They're admittedly less useful if you're already using component-based design. That's closer to something like BEM in hyper-targeting each element.

Sure, if there is a HTML element that works then use it, but not every UX pattern is expressible in HTML without specifying roles/attributes (e.g. tabs [1]) and not all browsers support recent HTML elements/attributes (such as using details/summary for accordions).

ARIA patterns [2] has a list of examples for UX components and their examples specify/use ARIA roles/attributes.

[1] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

[2] https://www.w3.org/WAI/ARIA/apg/patterns/

tailwind’s biggest problem is that it doesn’t make this distinction well.

In a sense this is a strength because it probably matches the amount of effort most devs/orgs who don’t focus here are willing to put in to the problem; this worse-is-better solution is functional enough especially in settings where component separation has already been adopted. Along with some decent baseline design tokens, it’s enough for people who don’t want to care more, especially if they don’t ever particularly see the consequences of hyperlocalizing implementation.

If your project has someone whose job it is to think through design systems and how they’re expressed via CSS, you can do better. If you don’t, you can do worse.

And personally, I’ve seen a LOT of discussion about separating SQL and app code. There’s a similar tension. Wrapping queries in function calls often means fewer duplicated queries (often painfully verbose) and opportunities for dumb security mistakes, but reduces the expressive variation the raw query language provides, and many systems and devs behind them end up pursuing balance between the two… or outsourcing the decision to an ORM or other data access layer whose tradeoffs also probably have shortcomings but at least they get to worse-is-better stop thinking about it except at particular pain points.

It’s like arguing that all of your source code should go in one big file because one file is less than two files, which means greater localization.

I don’t know anyone whose concerns with “presentation” in markup included the presence of classes — the dominant understanding among people I’ve known who care about this is that classes are semantic in the markup with names chosen for that purpose and they have presentation attached in stylesheets.

Tailwind gives up on that separation. There can be some worse-is-better benefits to that, especially for teams that don’t have anyone whose role is to care about this. But the “ugly as sin” is a signal about the shortcomings in the tradeoff.

The class attribute (not "property") is in the HTML because it's part of HTML. It's markup. Element classes weren't created either by or for the CSS people when CSS came along. The class attribute predates CSS by years and has no more relation to "styling info" than the id attribute does.

With LLMs Tailwind wins. Because it's a very restricted set of classes. With regular "separation of concerns" CSS, LLMs will happily just pile on more and more and more CSS because they can't really analyze the code that's already there, and will miss and re-create huge chunks of CSS. Or write increasingly hyper-specific CSS to fix reported issues.

Anecdotally: in a side project I now have 10k lines of "pure" CSS generated by LLMs on top of Tailwind. The web part of the app is ~20k lines (not all of them are rendering anything on screen). No idea how to fix it :)

But more seriously, I should have been more specific. Having the second file open in a split pain isn't that big of a deal, but having to navigate and find the right selectors can be. If class names are used well then it's pretty easy to find those, but my experience with that is riddled with inconsistency when I'm not the one who wrote it.

On that note, it's also much easier to review CSS changes in pull requests when they are right in line with the file. Otherwise I have to do the same lookup to find the corresponding HTML, and reason about whether the selector could potentially be grabbing things that aren't obvious, etc.

I’ve made setups like that on a number of projects (ASP.Net & various .Net web frameworks). keeping clean separation of concerns, proper cascading, but also a simplified development experience where the ‘component’ file contained all relevant code, markup, and local styling.

The problem is that HTML gives us very few tools to do anything useful. And you can only push certain elements so far. Div and span are generic elements with no semantics attached. You want a layout? Div. You want a change to a part of text? Span.

The only reason they are called "elements of last reserve" because it's only true if you remember that HTML is, has been, and forever will be a tool to display static text, badly. That's why you have article, section, p, and other text-oriented elements. But the moment you want something beyond that? Welcome to divs.

Very similar to early React where every component had to return a single real parent element (now you can return a fragment) so people chose div.

What I should've said in my hastily written comment should have been: "and other implementations of the same (or other) functionality isn't divs and spans?"

I think my only true criticisms for Tailwind example would be:

- should've probably used h2/h3 for card titles. Though this is dependent on where and how the card is used

- should've done more with the meta (number / date). But in a real world these would probably still be spans (for example, to mark them in different colors etc.)

HTML doesn't have a card element. So when you create one, you... use whatever's available. And divs and spans in HTML+CSS literally exist to manipulate layout and text.

BTW, my favorite accessible card is this one: https://inclusive-components.design/cards/ And it's probably even more weird. Demo: https://heydon.github.io/Inclusive-Components/cards-redundan... (check the CSS also)

This is what CSS classes were made for. Of all of the arguments in favor of Tailwind, this is the one that drives me battiest. Say what you will about CSS, but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get.

> And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component.

Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition!

> There's nothing precluding you from using an approach like DaisyUI if stock Tailwind has too much repetition for your taste.

...and now you have three problems.

But sure, like most tools, it starts with understanding how it works.

I meant physics of course!

You’re still not getting it. That’s NOT what Tailwind is, because Tailwind works in a design system way, so when you use text-sm or bg-sky-400, you’re using variables that can be configured to suit your needs and keep a consistent design everywhere. Tailwind defaults and configurability played a huge part in its success.