9 ms·

Does a preprocessor really complicate the workflow? Variables are still new and not fully supported. Being able to nest css selectors is major win for me. Re

Does a preprocessor really complicate the workflow? Variables are still new and not fully supported. Being able to nest css selectors is major win for me. Reusable mixins is another. I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.

wwweston 7y ago
I still use less & sass on most projects, but it's occurred to me that: * Duplicating the effect of mixins by just... having another css class for the mixed-in stuff works well enough for many cases (though this hurts most where you're trying for semantic selector naming conventions, with mixins adding in rulesets behind the scenes). * Nesting selectors save thinking and some typing regarding where styles cascade out to, but... tbh, yanking a high-resolution selector into the buffer and chucking it out onto another line was never a burdensome part of my pre- processor workflow. * Pretty sure free-use of nested selectors and mixins is trading larger CSS files for developer attention (which may or may not be a valid trade). * Variables... yeah, they're handy. Search-and-replace only goes so far. IE seems to be the holdup. For small or disciplined teams with the freedom & skill to really think about their CSS starting from a style-guide-first perspective rather than every-page-a-custom-layout perspective, I can see making the choice to do without. Especially if you've already ditched IE 11 support for other reasons.
- nine_k 7y ago
  Writing pure CSS and copy-pasting things here and there is easy when you start. Where SASS shines is when you need to do a coordinated change, e.g. these things become gray instead of black. You have a ton of black things so no search and replace. And once you've painstakingly determined and edited the classes, the hard part is to be sure that you only changed what you had to, and nothing unrelated. SASS preserves semantics which plain CSS is unable to express. It's like C vs assembly.
  - lugg 7y ago
    You mean variables? Because I've seen sass refactors go just as badly.
baroffoos 7y ago
I just looked it up and css variables are available on all current version browsers and have been available since about 2016/2017
- nkozyra 7y ago
  90% of users, which is a bit low for a lot of organizations. They also aren't a full sass/less replacement, just one aspect
rhizome 7y ago
Nesting is by far the biggest driver for me. I can do vanilla CSS in my sleep, but it's such a cognitive drag.
- gitgud 7y ago
  I feel that yes SASS requires less source code, but the nesting is kind of an anti-pattern and encourages complex hierarchies of styles which are hard to follow and maintain.
  - rhizome 7y ago
    How come I haven't experienced these downsides?
    - andykx 7y ago
      I'm with you. My SCSS is really just CSS with nesting. My CSS is cleaner without any downside. I've never experienced issues with maintainability, even in large CSS files.
    - pixelbash 7y ago
      That's where I am on this. Before nesting I had to take great care to avoid conflicts. I guess this is what BEM set out to solve, but it seems to have limitations.
      - BigJono 7y ago
        Why would sass have any effect on whether or not you have conflicts? You can just do things in plain CSS with descendant (' ') selectors, same as if they were nested in sass.
        mercer 7y ago
        Sure, but that's a bit like arguing that you don't need 'scope' for your variables and you can just prepend the function name (or multiple nested function names). Or that you don't need modules but can just put all your code in one file. At the very least support of nesting is a huge convenience, but in practice I've also found that it saves me from all sorts mistakes, whether it's because I'm being stupid, or refactoring things. That said, overusing nested selectors can be a problem too. I generally try to limit myself to two levels of nesting (component -> element), and then a third for pseudo-classes (:hover, :selected, etc.) and pseudo-elements (:before, etc.).
baddox 7y ago
Don't forget that SASS lets you use sane single-line comments prefixed by a double-slash. Heck, I'd use it just to avoid the laughably terrible /* CSS comment syntax */.
- tobr 7y ago
  It works in practice though, because there’s no CSS syntax that uses //, so you can basically turn off any line that way by causing a syntax error. CSS fault tolerance makes it just ignore the line. Not sure if it’s wise to do this, but it works.
  - baddox 7y ago
    That’s a valid point. I’ve never actually tried it, because my editor always tells that it’s wrong. I suppose I could edit raw CSS with my editor in SCSS mode and just be careful to not use any incompatible features. :)
marcus_holmes 7y ago
>>Does a preprocessor really complicate the workflow? I've just spent yesterday getting sass to work with my Golang project. I used to have a nice simple makefile task, that compiled the project (in a split second) and launched it on localhost so I could find out where the problems were. My only dependency was the Go compiler. If I changed the css, the next page refresh sorted it. Now I have a "sass watch" task, which compiles the scss to css. But that requires node.js, and npm (there are golang scss compilers, but all of them are either not being maintained, or have problems, or only support older versions of scss). I have to run this in a separate terminal so I can stop it when I need to. I've deliberately not looked at my global node_modules directory. If I don't look, I don't have to worry about how many js libraries just got installed on my machine, and I don't have to think about who's maintaining them, and if they're now malicious. As long as sass only touches the css files, and css isn't Turing-complete (yet), then I don't need to audit any of that, and I can assume that it's not injecting malicious code into my application. Though there are possible attacks on my site that could originate with code injection from a $malicious_left_pad js library, even via css, but it's enough of a stretch that my paranoia can live with it. I can check out the compressed css every now and again and see that it's not importing anything it shouldn't, and be reasonably sure that I haven't just compromised all my users' security. So yeah, it's not so much that a preprocessor is a complication, it's that a preprocessor allows a malicious package to compile whatever it likes into files that I will then serve from my domain to my users, who trust that I'm not serving them malicious files. That's policed not at all by npm, or any of the package managers, who cheerfully assume that all javascript developers are honest.
- stephenr 7y ago
  Use sassc and call it from your makefile.
  - jayshua 7y ago
    Not sure what it's like today, but last time I tried to use sassc it was a nightmare. The official repo was just the library with no CLI. I couldn't find a CLI that didn't also require me to compile it myself. Very frustrating.
simplify 7y ago
CSS variables are actually superior to SASS variables because you can change them at runtime via JS.
kowdermeister 7y ago
It does not. With Parcel for example it works out of the box and it even installs the dependencies automatically for you. I still love SASS since it solves many existing problems at once like you mentioned.
mo1ok 7y ago
in isolation, no, but the problem I've seen is that literal dozens of preprocessing steps for a javascript project, and these add significant cost over time. In a corporate environment, too, you need to proxy many of these, and set an environmental variable in the shell for SASS to install properly. Over time, this adds significant cost, pain, and stress to the install process.
daxterspeed 7y ago
Nested CSS selectors should be counted as a major win for everyone - to the point where there's proposals to support it in native CSS: https://github.com/w3c/csswg-drafts/issues/2701 https://github.com/w3c/csswg-drafts/issues/2701 My personal solution to avoid running watchers is to have a run-on-save task in VSCode that automatically compiles any "root" .scss file (eg */index.scss) into a .css file with an accompanying .css.map file.

wwweston 7y ago

I still use less & sass on most projects, but it's occurred to me that: * Duplicating the effect of mixins by just... having another css class for the mixed-in stuff works well enough for many cases (though this hurts most where you're trying for semantic selector naming conventions, with mixins adding in rulesets behind the scenes). * Nesting selectors save thinking and some typing regarding where styles cascade out to, but... tbh, yanking a high-resolution selector into the buffer and chucking it out onto another line was never a burdensome part of my pre- processor workflow. * Pretty sure free-use of nested selectors and mixins is trading larger CSS files for developer attention (which may or may not be a valid trade). * Variables... yeah, they're handy. Search-and-replace only goes so far. IE seems to be the holdup. For small or disciplined teams with the freedom & skill to really think about their CSS starting from a style-guide-first perspective rather than every-page-a-custom-layout perspective, I can see making the choice to do without. Especially if you've already ditched IE 11 support for other reasons.

nine_k 7y ago
Writing pure CSS and copy-pasting things here and there is easy when you start. Where SASS shines is when you need to do a coordinated change, e.g. these things become gray instead of black. You have a ton of black things so no search and replace. And once you've painstakingly determined and edited the classes, the hard part is to be sure that you only changed what you had to, and nothing unrelated. SASS preserves semantics which plain CSS is unable to express. It's like C vs assembly.
- lugg 7y ago
  You mean variables? Because I've seen sass refactors go just as badly.

baroffoos 7y ago

I just looked it up and css variables are available on all current version browsers and have been available since about 2016/2017

nkozyra 7y ago
90% of users, which is a bit low for a lot of organizations. They also aren't a full sass/less replacement, just one aspect

rhizome 7y ago

Nesting is by far the biggest driver for me. I can do vanilla CSS in my sleep, but it's such a cognitive drag.

gitgud 7y ago
I feel that yes SASS requires less source code, but the nesting is kind of an anti-pattern and encourages complex hierarchies of styles which are hard to follow and maintain.
- rhizome 7y ago
  How come I haven't experienced these downsides?
  - andykx 7y ago
    I'm with you. My SCSS is really just CSS with nesting. My CSS is cleaner without any downside. I've never experienced issues with maintainability, even in large CSS files.
  - pixelbash 7y ago
    That's where I am on this. Before nesting I had to take great care to avoid conflicts. I guess this is what BEM set out to solve, but it seems to have limitations.
    - BigJono 7y ago
      Why would sass have any effect on whether or not you have conflicts? You can just do things in plain CSS with descendant (' ') selectors, same as if they were nested in sass.
      - mercer 7y ago
        Sure, but that's a bit like arguing that you don't need 'scope' for your variables and you can just prepend the function name (or multiple nested function names). Or that you don't need modules but can just put all your code in one file. At the very least support of nesting is a huge convenience, but in practice I've also found that it saves me from all sorts mistakes, whether it's because I'm being stupid, or refactoring things. That said, overusing nested selectors can be a problem too. I generally try to limit myself to two levels of nesting (component -> element), and then a third for pseudo-classes (:hover, :selected, etc.) and pseudo-elements (:before, etc.).

baddox 7y ago

Don't forget that SASS lets you use sane single-line comments prefixed by a double-slash. Heck, I'd use it just to avoid the laughably terrible /* CSS comment syntax */.

tobr 7y ago
It works in practice though, because there’s no CSS syntax that uses //, so you can basically turn off any line that way by causing a syntax error. CSS fault tolerance makes it just ignore the line. Not sure if it’s wise to do this, but it works.
- baddox 7y ago
  That’s a valid point. I’ve never actually tried it, because my editor always tells that it’s wrong. I suppose I could edit raw CSS with my editor in SCSS mode and just be careful to not use any incompatible features. :)

marcus_holmes 7y ago

>>Does a preprocessor really complicate the workflow? I've just spent yesterday getting sass to work with my Golang project. I used to have a nice simple makefile task, that compiled the project (in a split second) and launched it on localhost so I could find out where the problems were. My only dependency was the Go compiler. If I changed the css, the next page refresh sorted it. Now I have a "sass watch" task, which compiles the scss to css. But that requires node.js, and npm (there are golang scss compilers, but all of them are either not being maintained, or have problems, or only support older versions of scss). I have to run this in a separate terminal so I can stop it when I need to. I've deliberately not looked at my global node_modules directory. If I don't look, I don't have to worry about how many js libraries just got installed on my machine, and I don't have to think about who's maintaining them, and if they're now malicious. As long as sass only touches the css files, and css isn't Turing-complete (yet), then I don't need to audit any of that, and I can assume that it's not injecting malicious code into my application. Though there are possible attacks on my site that could originate with code injection from a $malicious_left_pad js library, even via css, but it's enough of a stretch that my paranoia can live with it. I can check out the compressed css every now and again and see that it's not importing anything it shouldn't, and be reasonably sure that I haven't just compromised all my users' security. So yeah, it's not so much that a preprocessor is a complication, it's that a preprocessor allows a malicious package to compile whatever it likes into files that I will then serve from my domain to my users, who trust that I'm not serving them malicious files. That's policed not at all by npm, or any of the package managers, who cheerfully assume that all javascript developers are honest.

stephenr 7y ago
Use sassc and call it from your makefile.
- jayshua 7y ago
  Not sure what it's like today, but last time I tried to use sassc it was a nightmare. The official repo was just the library with no CLI. I couldn't find a CLI that didn't also require me to compile it myself. Very frustrating.

simplify 7y ago

CSS variables are actually superior to SASS variables because you can change them at runtime via JS.

kowdermeister 7y ago

It does not. With Parcel for example it works out of the box and it even installs the dependencies automatically for you. I still love SASS since it solves many existing problems at once like you mentioned.

mo1ok 7y ago

in isolation, no, but the problem I've seen is that literal dozens of preprocessing steps for a javascript project, and these add significant cost over time. In a corporate environment, too, you need to proxy many of these, and set an environmental variable in the shell for SASS to install properly. Over time, this adds significant cost, pain, and stress to the install process.

daxterspeed 7y ago

Nested CSS selectors should be counted as a major win for everyone - to the point where there's proposals to support it in native CSS: https://github.com/w3c/csswg-drafts/issues/2701 https://github.com/w3c/csswg-drafts/issues/2701 My personal solution to avoid running watchers is to have a run-on-save task in VSCode that automatically compiles any "root" .scss file (eg */index.scss) into a .css file with an accompanying .css.map file.