5 ms·

Speaking Up for Sass (2021)

43 points by lioeters 4y ago

pier25 4y ago
Sass is awesome and still the most popular way of writing CSS according to the State of CSS surveys. A day might come when we'll be able to just write vanilla CSS but we're not there yet.
- ravenstine 4y ago
  > A day might come when we'll be able to just write vanilla CSS but we're not there yet. Ummm... what? You can already just write vanilla CSS. It doesn't have all the features of Sass, but it's perfectly usable, especially if cascading is used sparingly.
  - danielvaughn 4y ago
    Pretty sure OP was being sarcastic
  - pier25 4y ago
    When I mean vanilla CSS I mean just that. No bundler or anything else, like we did in the good old days. Even if using the latest features at least a bundler is still needed for most projects.
- spankalee 4y ago
  Lots of people write large-scale vanilla CSS today, especially in the Lit community where we have native style scoping and where CSS strings are embedded in JS modules so we get proper import-based loading, sharing, and bundling.
  - pier25 4y ago
    lol CSS in JS is definitely not vanilla CSS.
    - spankalee 4y ago
      It's vanilla CSS strings. No alternate syntax.
clairity 4y ago
two things that sass has that i want to see in plain ol' css: 1. nesting - but this is coming! 2. mixins - not even static mixins are coming =( static mixins might seem to be limited in utility at first, but it'd alleviate a lot of duplicate css by allowing you to have orthogonal groups of styles. so you could have sets of static mixins for borders/shadows, spacing, layout, fonts, etc. that you could mix and match into both element and class styles as you need. too much nesting can lead to a rat's nest of css (ha), but shallow nesting (1 level mostly, 2 levels on occasion) adds clarity and structure.
- xboxnolifes 4y ago
  Nesting is basically the only reason I always use sass, even in small projects. Will be happy when that comes to css.
  - JimDabell 4y ago
    That’s been available for years with PostCSS. You can use a lot of tomorrow’s CSS today with PostCSS Preset Env.
    - xboxnolifes 4y ago
      Aren't both sass and postcss supersets of css that require transformation plugins? What am I gaining from switching from sass to postcss here?
      - elondaits 4y ago
        Nothing, because also PostCSS is a specific program, while there’s a ton of ways to compile SCSS… Ruby, node-js, built-in compiler in the IDE, GUI frontends, etc.
  - purplerabbit 4y ago
    Posted on another thread and haven’t heard an answer, so I’ll post it here too… Serious question: how do you refactor code when using nesting? In my experience it makes styles impossible to audit.
kuramitropolis 4y ago
brycewray 4y ago
Author here. Thanks to lioeters for posting this.
deleted 4y ago
[deleted]
seanwilson 4y ago
> Tailwind adherents say this isn’t a problem because, once you recognize that you’re re-using certain Tailwind classes too frequently, you then simply extract them to reusable components and then @apply them, as the Tailwind documentation suggests. I agree that this is a workable strategy, but my own experience suggests it can get out of hand quickly, even in a small project. The @apply approach is really only for single-div components or as a last resort. The default way you should be reusing styles when using utility classes is to extract each component into its own HTML template file so you can update its styles from a central place e.g. your hero header might go in a file called hero-header.html along with all the relevant HTML + utility classes so you can update it from a central place. I think this is really central to understanding Tailwind's claim of being scalable when compared to the traditional way of using CSS classes. The examples here are worth considering carefully (especially if your knee-jerk reaction is "it's just inline styles and inline styles are bad practice!"): https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/utility-first https://tailwindcss.com/docs/utility-first > There are numerous pieces on the web saying that one of the biggest hassles in dealing with code is naming things (e.g., variables, functions, and CSS classes), and that this is a pain which Tailwind can remedy by keeping you from having to name more than a handful of CSS classes. You'll still have names for your component files and you can add comments to the HTML if needed. Will you really miss classes like `hero-inner-container-wrapper' that you were forced to add to a `div` to apply a single class? A lot of `div`s like this won't have meaningful names because they're purely presentational or were only added to get around some CSS limitation.
RobotToaster 4y ago
I thought this article was going to be a defence of being cheeky.
KronisLV 4y ago
I still use Sass for some projects and find it perfectly sufficient in most cases. Because of this, I don't really see moving away from it anytime soon: it feels like a nice little addition on top of CSS, that's not overbearing and most people can also get up to speed with the features that it provides. Nesting being one of the things that I think CSS should have had out of the box, but that might change for the better eventually: https://www.w3.org/TR/css-nesting-1/ https://www.w3.org/TR/css-nesting-1/ That said, various CSS component frameworks, utility class frameworks (or libraries) also seem nice, from Tailwind or maybe PrimeFlex (which feels nice with PrimeVue or PrimeReact), all the way back to aspects of that approach in Bootstrap. Things can get a little bit messy when you mix both of the approaches a lot, though. Parts of the style are in the utility classes but for some reason you also have your own custom classes and so on, which I've seen sometimes.
fleddr 4y ago
I feel obliged to share a gotcha regarding nesting... The idea of nesting in SASS/SCSS is that you need a combination of selectors, and you don't want to repeatedly type out the first one. What I often see though is developers using it as grouping structure, closely mimicking the nesting of the markup they're working with. This is massively convenient from an authoring point of view, but it leads to issues. For complicated components, I've seen output consisting of 12 selectors after each other, whilst only 2 would be needed. Not only does this lead to verbose output, it also makes that style rule extremely specific. In case you ever need to overrule it, you'd need 13 selectors or an !important. To illustrate: .selector1 .selector2 ........all the way up to .selector 12 Or: .selector1 .selector12 Example 2 is what you want. You got your parent scope and after that it doesn't matter where .selector12 is in the markup, assuming you use something like BEM. The 10 nesting levels in between are completely pointless.

43 points by lioeters 4y ago

Sass is awesome and still the most popular way of writing CSS according to the State of CSS surveys. A day might come when we'll be able to just write vanilla CSS but we're not there yet.

ravenstine 4y ago
> A day might come when we'll be able to just write vanilla CSS but we're not there yet. Ummm... what? You can already just write vanilla CSS. It doesn't have all the features of Sass, but it's perfectly usable, especially if cascading is used sparingly.
- danielvaughn 4y ago
  Pretty sure OP was being sarcastic
- pier25 4y ago
  When I mean vanilla CSS I mean just that. No bundler or anything else, like we did in the good old days. Even if using the latest features at least a bundler is still needed for most projects.
spankalee 4y ago
Lots of people write large-scale vanilla CSS today, especially in the Lit community where we have native style scoping and where CSS strings are embedded in JS modules so we get proper import-based loading, sharing, and bundling.
- pier25 4y ago
  lol CSS in JS is definitely not vanilla CSS.
  - spankalee 4y ago
    It's vanilla CSS strings. No alternate syntax.

clairity 4y ago

two things that sass has that i want to see in plain ol' css: 1. nesting - but this is coming! 2. mixins - not even static mixins are coming =( static mixins might seem to be limited in utility at first, but it'd alleviate a lot of duplicate css by allowing you to have orthogonal groups of styles. so you could have sets of static mixins for borders/shadows, spacing, layout, fonts, etc. that you could mix and match into both element and class styles as you need. too much nesting can lead to a rat's nest of css (ha), but shallow nesting (1 level mostly, 2 levels on occasion) adds clarity and structure.

xboxnolifes 4y ago
Nesting is basically the only reason I always use sass, even in small projects. Will be happy when that comes to css.
- JimDabell 4y ago
  That’s been available for years with PostCSS. You can use a lot of tomorrow’s CSS today with PostCSS Preset Env.
  - xboxnolifes 4y ago
    Aren't both sass and postcss supersets of css that require transformation plugins? What am I gaining from switching from sass to postcss here?
    - elondaits 4y ago
      Nothing, because also PostCSS is a specific program, while there’s a ton of ways to compile SCSS… Ruby, node-js, built-in compiler in the IDE, GUI frontends, etc.
- purplerabbit 4y ago
  Posted on another thread and haven’t heard an answer, so I’ll post it here too… Serious question: how do you refactor code when using nesting? In my experience it makes styles impossible to audit.

kuramitropolis 4y ago

brycewray 4y ago

Author here. Thanks to lioeters for posting this.

deleted 4y ago

[deleted]

seanwilson 4y ago

> Tailwind adherents say this isn’t a problem because, once you recognize that you’re re-using certain Tailwind classes too frequently, you then simply extract them to reusable components and then @apply them, as the Tailwind documentation suggests. I agree that this is a workable strategy, but my own experience suggests it can get out of hand quickly, even in a small project. The @apply approach is really only for single-div components or as a last resort. The default way you should be reusing styles when using utility classes is to extract each component into its own HTML template file so you can update its styles from a central place e.g. your hero header might go in a file called hero-header.html along with all the relevant HTML + utility classes so you can update it from a central place. I think this is really central to understanding Tailwind's claim of being scalable when compared to the traditional way of using CSS classes. The examples here are worth considering carefully (especially if your knee-jerk reaction is "it's just inline styles and inline styles are bad practice!"): https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/utility-first https://tailwindcss.com/docs/utility-first > There are numerous pieces on the web saying that one of the biggest hassles in dealing with code is naming things (e.g., variables, functions, and CSS classes), and that this is a pain which Tailwind can remedy by keeping you from having to name more than a handful of CSS classes. You'll still have names for your component files and you can add comments to the HTML if needed. Will you really miss classes like `hero-inner-container-wrapper' that you were forced to add to a `div` to apply a single class? A lot of `div`s like this won't have meaningful names because they're purely presentational or were only added to get around some CSS limitation.

RobotToaster 4y ago

I thought this article was going to be a defence of being cheeky.

KronisLV 4y ago

I still use Sass for some projects and find it perfectly sufficient in most cases. Because of this, I don't really see moving away from it anytime soon: it feels like a nice little addition on top of CSS, that's not overbearing and most people can also get up to speed with the features that it provides. Nesting being one of the things that I think CSS should have had out of the box, but that might change for the better eventually: https://www.w3.org/TR/css-nesting-1/ https://www.w3.org/TR/css-nesting-1/ That said, various CSS component frameworks, utility class frameworks (or libraries) also seem nice, from Tailwind or maybe PrimeFlex (which feels nice with PrimeVue or PrimeReact), all the way back to aspects of that approach in Bootstrap. Things can get a little bit messy when you mix both of the approaches a lot, though. Parts of the style are in the utility classes but for some reason you also have your own custom classes and so on, which I've seen sometimes.

fleddr 4y ago

I feel obliged to share a gotcha regarding nesting... The idea of nesting in SASS/SCSS is that you need a combination of selectors, and you don't want to repeatedly type out the first one. What I often see though is developers using it as grouping structure, closely mimicking the nesting of the markup they're working with. This is massively convenient from an authoring point of view, but it leads to issues. For complicated components, I've seen output consisting of 12 selectors after each other, whilst only 2 would be needed. Not only does this lead to verbose output, it also makes that style rule extremely specific. In case you ever need to overrule it, you'd need 13 selectors or an !important. To illustrate: .selector1 .selector2 ........all the way up to .selector 12 Or: .selector1 .selector12 Example 2 is what you want. You got your parent scope and after that it doesn't matter where .selector12 is in the markup, assuming you use something like BEM. The 10 nesting levels in between are completely pointless.