What's your favorite CSS approach?

Some time ago I wrote an extended article on various approaches to styling in 2020. Some of the most common CSS ways include:

• Vanilla CSS
• Supersets like SASS/SCSS, Less, Stylus
• Frameworks like Bootstrap, Foundation, Bulma, Materialize, Semantic UI
• CSS-in-JS approaches like Styled-components, Radium, Aphrodite, Emotion, and JSS
• Atomic CSS and low-level utility frameworks like TailwindCSS

Which approach is your favorite and why?

Comments

[𒎏Wii 🏳️‍⚧️]

My personal rules of thumb:

• Vanilla CSS
• Axiomatic CSS whenever possible
• Prefer describing to naming (nth-child(1) over .item-1)
• Classes should be semantic (otherwise use attribute selectors)
• Avoid frameworks, they are garbage
• CSS-in-JS should be aggressively refactored into CSS as soon as it becomes complex

As a result, I consider the following a code smell:

• More than a few elements have classes
• More than very few id-selectors
• Long selector chains
• More than one class / id in one selector
• Stylesheets that would be very hard to rewrite without a preprocessor

[Giorgos Sarigiannidis]

I agree on nesting. I enjoy it on SASS, but I try to keep it under control and style elements mostly on a first-level basis, as it makes it easier to override styles on specific occasions or move entire components between projects.

Also:

• I try to avoid styling based on tag names. Eg. instead of styling h2, p, or figure, I prefer to assign specific classes. That way it is easier to change the markup if needed without affecting the appearance.
• I try to keep the markup as clean as possible, avoiding empty spans for decoration purposes, and prefer ::before & ::after pseudoelements instead.
• I try to avoid using "all" in transitions and prefer to use only the properties that actually need the effect (e.g. an opacity), as it should be more performant.

[𒎏Wii 🏳️‍⚧️]

I try to avoid styling based on tag names [...] I prefer to assign specific classes.

That's precisely what I mean when I say prefer describing to naming: write selectors that describe an element (its tag name, position, its parents, etc.) instead of specifically naming them (aka. class and id selectors). That way you keep styling and markup clearly separated.

I try to avoid using "all" in transitions

Never used that and actually didn't even know that was a thing until recently.

[Ben Sinclair]

That's pretty much exactly my POV except I do enjoy nesting things with Sass.

[𒎏Wii 🏳️‍⚧️]

There's nothing wrong with nesting things; it's just that nesting makes it very easy to hide structural problems because you don't have to manually write long selector chains. In plain CSS it's more obvious when you're being way too specific.

[Louis Low]

I hate to say this, I use Yogurt to craft a user interface for my embedded projects and mainstream web projects that require SEO compliant. Fast UI prototyping on the spot when sitting together with my client (1 meter social-distancing).

[Madza]

Good job on it, overall well-thought-out framework 👌👍
Def needs more exposure 😉 Didn't you re-spray the UI of its website recently? 🎨

[Louis Low]

(JOKE)

This is one of my kind of Adobe Photoshop in embedded development.

As for User Interface, I am using (C/C++/Python/Bash) and (NodeJS/HTML/CSS/JS). Yea, pretty modern right? That's why I created Yogurt that have the option to ignore the SEO, which is embedded that don't need anyway.

[Louis Low]

Yea, thanks. I need to do this because I'll be busy when back into my usual embedded engineering projects. I will be away from the web development for a while.

[Tobias Nickel]

pure CSS in a single file. Does that sounds strange to you? let me explain.

With this setup Chrome with its dev-tools almost becomes a design tool. Click on an element, add the class to the css file (inside chrome), add some properties, see live how it changes. not knowing all css vocabulary and keywords does not matter, just try a few. When it looks good, copy the complete css and drop it into your css file in your editor.

the theme changes, just click at the items adjust it. This way, you can just go, without thinking ahead and defining variables that might or might never change. greatly reducing overhead and boilerplate in your styles.

[𒎏Wii 🏳️‍⚧️]

I totally agree. Plain CSS makes it super easy to change stuff with chrome and it even reloads the CSS automatically when you change it in the editor.

Custom properties (aka "CSS variables") make preprocessors mostly redundant anyway.

[Vesa Piittinen]

For this I prefer Firefox because

Chrome does not tell me things like this that I do want to know.

[Pontakorn Paesaeng]

My favorite one is TailwindCSS + PostCSS. It is more than enough for quick job such as. prototyping and rapid showcase. Also I can include as many plugins as I want to power PostCSS more such as PreCSS which make PostCSS look like SCSS, Autoprefixer, PurgeCSS.

[Michel Renaud]

I just inherited a prototype that uses these.

[Giorgos Sarigiannidis]

I avoid CSS frameworks (here is my reasoning) but I use SASS for better organization, mostly because I find it convenient to break the CSS into many different files. Variables and mixins were a big plus as well, but with native CSS custom properties, there's not much need for those anymore. Nesting is also a convenient feature, even though I try to be very careful and nest selectors only when I have to.

[Pacharapol Withayasakpunt]

• <style scoped> (In Next.js, there is <style jsx>, but it seems not to be truly injected CSS first into stylesheets.)
• CSS modules (with Webpack)
• SCSS for Webpack-based environment. I am considering LESS for browser-based on-the-fly compilation. (I have been using Stylis.)

Lastly, all of these are easy in making "components" using Nuxt. Though, I regretted that :host selector is still missing.

[Etienne Burdet]

Global variables + scoped styles (mainly through Sass and Svelte). Eventually with pure CSS framework to avoid reimplementing well known things (Bulma is really good at that).

Global variables ensure coherence over the whole project. Scoped style per components make selectors easy and removes much of the naming headache.

[Dennis Frijlink]

My favorite is Bulma with PurgeCSS. Most of the time I write my CSS by myself. But I use things like 'responsive grids' from css libraries. Bulma has a great documentation, high popularity, a lot of opportunities and is based on flexbox. Bulma consists of 39 .sass files that you can import individually.

If you use the whole Bulma I prefer to use it together with PurgeCSS.

[Ben Sinclair]

My favourite approach is Sass coupled with semantic HTML. Avoiding making changes to the HTML just to accommodate appearance.

I'd prefer if the nesting of scss was part of CSS, but it'll be there soon enough, and then Sass won't be useful any more.

[Tommy May III]

Utility CSS frameworks are my favorite but I understand why it turns some people away. My second favorite approach is BEM with light use of SASS to make the nesting clear. If I see things like functions in SASS I consider that to be too much for my taste.

The main benefits of utility first CSS for me is:

1. Your CSS files tend to not grow very large because you reuse the same code over and over.
2. Everything has the same specificity. This point can not be overstated. I have ran into so many codebases where I have to write some ridiculous CSS that just adds mental fog for everyone that reads it because I have to override that ul > li + a.some-class selector.
3. No more trying to make generic class names that mean nothing like .container just so you can reuse it in multiple places and still have the class make sense.

I understand this is a holy war, and I'm really not trying to argue with anyone today, tomorrow, or the next day. All the approaches of writing CSS can be made to work.