this post was submitted on 30 Jun 2025
413 points (97.9% liked)

Programmer Humor

24648 readers
346 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] 0x01@lemmy.ml 24 points 1 day ago (4 children)

Ngl I love tailwind, I've been through so many different css paradigms

  • separate css files: why did we ever do this, if you've ever used kendo's css stuff you'll understand how unfathomable hundreds of thousands of lines of css with complex rules is. Identifying all the things that affect a single component is the work of dozens of minutes at minimum, sometimes hours, you have to understand every nook and cranny of the css spec.
  • inline styles: fine, but verbose and requires object spreading, harder to compose, theming is tough and requires discipline to be consistent in your theme conventions, almost impossible to also theme imported library components
  • module.css with imported classes: my go to outside of tailwind
  • scss: I actually really like scss but it exacerbates the complexity and mystery of css, great for small projects but terrible as projects bloat
  • bootstrap: basically just worse tailwind, providing only components and colors

That's all I can think of right now, but tailwind is my preferred way to style a new project, I love how easy theming and style consistency is

[–] Jesus_666@lemmy.world 9 points 1 day ago

Honestly, I'm still very much in the "classes define what a tag represents, CSS defines how it looks" camp. While the old semantic web was never truly feasible, assigning semantic meaning to a page's structure very much is. A well-designed layout won't create too much trouble and allows for fairly easy consistency without constant repetition.

Inline styles are essentially tag soup. They work like a print designer thinks: This element has a margin on the right. Why does it have that margin? Who cares, I just want a margin here. That's acceptable if all you build are one-off pages but requires manual bookkeeping for sitewide consistency. It also bloats pages and while I'm aware that modern web design assumes unmetered connections with infinite bandwidth and mobile devices with infinitely big batteries, I'm oldschool enough to consider it rude to waste the user's resources like that. I also consider it hard to maintain so I'd only use it for throwaway pages that never need to be maintained.

CSS frameworks are like inline styles but with the styles moved to classes and with some default styling provided. They're not comically bad like inline styles but still not great. A class like gap-2 still carries no structural meaning, still doesn't create a reusable component, and barely saves any bandwidth over inline CSS since it's usually accompanied by several other classes. At least some frameworks can strip out unused framework code to help with the latter.

I don't use SCSS much (most of its best functionality being covered by vanilla CSS these days) but it might actually be useful to bridge the gap between semantically useful CSS classes and prefabricated framework styles: Just fill your semantic classes entirely with @include statements. And even SCSS won't be needed once native mixins are finished and reach mainstream adoption.

Note: All of this assumes static pages. JS-driven animations will usually need inline styles, of course.

[–] TrickDacy@lemmy.world 9 points 1 day ago* (last edited 1 day ago)

I've never quite understood how adding all these HTML classes to a page is supposed to be clean. Just do a decent job of organizing your code and it's honestly not that hard to keep from breaking styles unexpectedly. This is the part you tell me "well that only works for small projects". Not really, it works when styles are managed carefully. I've worked on fairly large sites with what modern standards would call "bad" css practices and it was fine, we just had an understanding that some devs were frontend (I was lead for a couple years at this particular company I'm thinking of) and some were backend. The backend people botched styles every time so we forbade them eventually. I think that contextless type of "help" is where people get the idea that you have to have a css setup that prevents people from breaking anything unexpectedly. CSS just gets no respect. You wouldn't let a frontend guy go changing your core backend code so why is the reverse ok?

I like css modules too but I totally disagree that css is irreparably broken and needs some system that discourages the cascade of styles in all cases.

[–] kautau@lemmy.world 0 points 1 day ago* (last edited 17 hours ago)

Working on hobby or shorter lived projects makes all your points agreeable. My work is generally on enterprise SaaS software with vast lifecycle and my thinking is

separate css files

module.css with imported classes: my go to outside of tailwind

These are the same thing, unless it's not configured correctly.

inline styles

Only makes sense for something computed. Like a color computed based on a user selection. Otherwise it should be a class

scss

On a well-maintained project SCSS should be second nature. Something like a Vue single-file component project with scss will certainly not add to the bloat. You'd just have extra lines of vanilla css to scope classes and children selection/scoping that scss does with better syntax, in addition to scss functions and the like. Note that CSS is improving to do the work that SCSS has previously done, just as JS is improving to do the work natively that frameworks, libraries, and toolkits have previously done.

bootstrap

Yeah bootstrap, like jQuery, had it's time. It's largely been replaced by native tooling that shouldn't require external libraries. There's plenty of CSS libraries that are purely for theming, which is mostly what people used bootstrap for. (Smart defaults, basic component and typography themes, etc).

To me tailwind makes sense for setting up projects quickly, but gets out of hand when it comes to customization on a larger scale. You eventually end up with overrides to tailwind's default styles that become hard to manage, outside of the scope of their theming implementation, and then ironically you're usually just using CSS variables which is back to the core toolkit.

[–] MonkderVierte@lemmy.zip 0 points 1 day ago (1 children)

Would be fine if it used a custom parameter for their tags. Using class names makes for bad accessibility.

[–] FooBarrington@lemmy.world 3 points 1 day ago (2 children)

How are class names relevant for accessibility?

[–] TrickDacy@lemmy.world 3 points 1 day ago

They might mean class names can't help screen readers parse meaning, whereas using the correct tag can?

[–] MonkderVierte@lemmy.zip 1 points 1 day ago* (last edited 1 day ago) (1 children)

https://lemmy.zip/comment/19872383

Usability by third-parties. A webpage is not a pdf.

[–] FooBarrington@lemmy.world 1 points 1 day ago (1 children)
[–] MonkderVierte@lemmy.zip 1 points 1 day ago (1 children)

You think only aria-attributes are accessibility? Most accessible is, what you not need additional tools and interpreters for.

[–] FooBarrington@lemmy.world 1 points 1 day ago (1 children)

No, it's of course not just aria attributes. But it's definitely not "how easy can I create user CSS". Accessibility is a term of art, you can't just expand its meaning to whatever you want.

https://en.wikipedia.org/wiki/Accessibility

[–] MonkderVierte@lemmy.zip -2 points 1 day ago* (last edited 1 day ago)

Look, if it hinders me in my workarounds for my ADHD while every other framework does less so, then accessibility is worse. Shut up with your trademark gatekeeping bullshit.

Also,