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 12 hours 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.

load more comments (10 replies)