Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

Post reply on HN
Print view View original

391–400 of 435 posts

Re: Moving away from Tailwind, and learning to structure my CSS

#391

Post by atoav »

danaw wrote: post #54
TonyAlicea10 wrote: post #3

> I got curious about what writing more semantic HTML would feel like. I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers. The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS. HTML is marking up the meaning of the document. You should start there. Then style with CSS.…

you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps can tailwind be used poorly? absolutely. but that's true of any tool i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled…

The first example on the official tailwind website right now starts like this:

  ...
The problem with tailwind is that semantic HTML should be entirely free of styling decisions in the ideal case. That also goes for styling classes like flex flex-col etc.

The way I would do it is to give the HTML some semantic meaning:

  ...
We can then decide how to treat section.info-for-nerds. Someone who reads the HTML immediately knows that this section is the bit that gives slightly too much information for nerds. That is what semantic means. The class adds meaning in a semantic sense, that helps to interpret the purpose of the element.

Then in CSS you would just style the semantic.info-for-nerds text fully with flex, flex-col, the whole shabang. If there are other info boxes that share style adding a general info-box class is probably a good idea. Again, this is semantic. I don't say red-box. I say what the box is intended to mean, not how it looks.

If you need the Infobox to look different in another context (or want to be sure your selector doesn't leak) you use the cascading bit of the language;

  .page-article>article>section.info-for-nerds { ... }
  
  .page-catalog>section.summary>section.info-for-nerds { ... }
Notice btw. that I also prefer to use semantic HTML elements like section, article, main, aside over generic ones like div. Using these well may even mean you don't need any classes at all. If you have three nested divs classes are the only way to k ow which one is the article. If you have main containing article containing section, that may literally be all the info you need.

Re: Moving away from Tailwind, and learning to structure my CSS

#392

Post by culi »

efortis wrote: post #316
culi wrote: post #305

Earlier quoted context omitted.

Don't most modern CSS tools create unique class names? I know styled-components did. Recently I've been using linaria which is a drop-in replacement for styled-components (exact same API) but its zero runtime. All the CSS is compiled during build (similar to vanilla extract, panda CSS, etc). I really prefer things like styled-components or Linaria or CSS Modules where you can just write straight up CSS. If you ever d…

True, I didn't mean to omit other solutions, I thought styled-components were deprecated after React 18.

Yeah they are not supporting server components. That's why I said I used Linaria which is a drop-in replacement. Exact same API so any team can simply run a codemod tool to change the import rule from styled-components to linaria

Re: Moving away from Tailwind, and learning to structure my CSS

#393

Post by culi »

madkat wrote: post #390
efortis wrote: post #316

Earlier quoted context omitted.

True, I didn't mean to omit other solutions, I thought styled-components were deprecated after React 18.

Yeah it was/is (doesn't work with server components). That's the reason we built next-yak ( https://yak.js.org ) as an alternative.

Thanks for your work on Yak. When I was evaluating the alternatives to styled-components, I went with Linaria over next-yak because it is zero runtime. Any plans for Yak to support this as well?

Re: Moving away from Tailwind, and learning to structure my CSS

#394

Post by chaosharmonic »

chaosharmonic wrote: post #89
JimDabell wrote: post #27

One thing that has always struck me about Tailwind is that practically every argument its proponents use more or less boils down to “I never learnt CSS beyond a junior level” . It’s super common to hear Tailwind advocates say things like “Without Tailwind, we would just have one big disorganised CSS file that always grows uncontrollably and ends up with loads of obsolete stuff in it and !important everywhere! Tailwin…

Personally, I'm not sure from my own dives into it that I'd still insist on bare CSS in a professional codebase any more than I'd insist on plain DOM manipulation. And I do at least see Tailwind classes as being a little less of a DSL than other, similar tools. But while I'm not going to be a purist about it at a workplace, I both agree with you and have noticed a layer even beyond your point: that overreliance on th…

I should probably note a detail I left out here: I myself care a lot about standards, and simply am stating that I wouldn't push teams around me to suddenly drop Tailwind even if I personally would rather not have to rely on things like it everywhere. Less that my opinion goes away and more that I don't presume it's the only valid option at scale.

But in my personal projects, I myself have just stopped using libraries entirely for styling.

Re: Moving away from Tailwind, and learning to structure my CSS

#395

Post by wwweston »

aleksiy123 wrote: post #237
mcv wrote: post #235

Earlier quoted context omitted.

I agree. I don't really like Tailwind, nor similar CSS frameworks. The whole idea was to separate styling from HTML, and Tailwind is putting it back into HTML through the backdoor. It's just a way to do styling from your HTML without having to touch the CSS, by inserting styling info in your HTML. That's exactly what we were trying to move away from.

I think this assertion is where most of the conflict comes from. There is a fair amount of people that disagree with the premise that it should be separated in that way (Including me). I personally like this essay by the author of htmx on the topic https://htmx.org/essays/locality-of-behaviour/ Also just better composition imo. Practically I think this means components of scoped css, html, js. People never seem to ha…

> it is important to make the distinction between inlining the implementation of some behaviour and inlining the invocation (or declaration) of some behaviour

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.

Re: Moving away from Tailwind, and learning to structure my CSS

#396

Post by wwweston »

isleyaardvark wrote: post #352
mcv wrote: post #235

Earlier quoted context omitted.

I agree. I don't really like Tailwind, nor similar CSS frameworks. The whole idea was to separate styling from HTML, and Tailwind is putting it back into HTML through the backdoor. It's just a way to do styling from your HTML without having to touch the CSS, by inserting styling info in your HTML. That's exactly what we were trying to move away from.

This is the misconception that has caused so many problems over the years, problems that the Tailwind approach solves. There was never any separation of concerns within the HTML code, the class="" property is in the HTML and that is the styling info. Devs took the idea of separation of concerns of content, presentation, and behavior as separation of technologies: HTML, CSS, and JS, which is not the same. So they tend…

HTML is content because it inflects content with structure and meaning. It may be fair to say it carries less of the semantic weight than the language and other media it marks up, but it’s content at least to the extent that punctuation is, and perhaps more.

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.

Re: Moving away from Tailwind, and learning to structure my CSS

#397

Post by 9dev »

miyoji wrote: post #388
9dev wrote: post #121

Earlier quoted context omitted.

Sure it's possible, but is it possible for everyone on your team? Including the new hire, the interns, or the now-vibecoding managers? Sooner or later it deteriorates.

> Sure it's possible, but is it possible for everyone on your team? Including the new hire, the interns, or the now-vibecoding managers? Why aren't we asking this about any of the things that are actually hard? Like any programming language, or databases, or caching... CSS is the easiest part of the web stack.

> Why aren't we asking this about any of the things that are actually hard?

We do. That's what countless abstraction layers, linters, frameworks, style guides, and CI checks are for.

> CSS is the easiest part of the web stack.

…and because programmers keep thinking that, they stay ignorant about CSS and structuring the styles properly - leading to the problems I described above.

Re: Moving away from Tailwind, and learning to structure my CSS

#398

Post by 9dev »

satvikpendem wrote: post #367
9dev wrote: post #351

Earlier quoted context omitted.

They don't, really. The only thing they solve is side effects, but you'll still want shared conventions across your modules.

If you're using components, it's the same as Tailwind, just put your CSS module files next to the component, or use compile time CSS in TS frameworks like PandaCSS to have them in the code itself. For shared conventions that is the purview of the design system and you'd have CSS tokens for various colors etc. Anything you can do in Tailwind you can of course do in CSS modules because it's CSS at the end of the day.

That isn't just CSS modules, then, but additional tooling on top.

Re: Moving away from Tailwind, and learning to structure my CSS

#399

Post by _the_inflator »

alwillis wrote: post #135
danaw wrote: post #54

Earlier quoted context omitted.

you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps can tailwind be used poorly? absolutely. but that's true of any tool i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled…

> tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change. Abstractions like a hero image, a menu, a headline? Sure, it's easy to overthink things but most of the time, it's not that complex. > placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors In my opinion, it's the opposit…

Trashing without offering a hands down solution is academic and therefore can safely be rejected.

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.

Re: Moving away from Tailwind, and learning to structure my CSS

#400

Post by extra88 »

stefan_lec wrote: post #307
extra88 wrote: post #194

Earlier quoted context omitted.

If Tailwind lends itself to using pixels instead of relative units for things that should be relative (like font-size, line-height, etc.), that's a problem. For those users, the HTML elements matter less unless they're savvy users who have custom user stylesheets to selectively adjust the appearance of content instead of changing everything on the page by zooming (e.g. make links, buttons, paragraphs, list items bigg…

This is not true. Tailwind defaults to rem as the underlying length unit for almost everything. You have to go to extra effort in most cases to use px.

Note the word "if" at the beginning.
Post reply on HN