12 ms·

Stepping Away from Sass

211 points by spking 8y ago

statictype 8y ago
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 8y 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 8y 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 8y ago
      You mean variables? Because I've seen sass refactors go just as badly.
- baroffoos 8y 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 8y 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 8y 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 8y 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 8y ago
      How come I haven't experienced these downsides?
      - andykx 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y ago
    Use sassc and call it from your makefile.
    - jayshua 8y 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 8y ago
  CSS variables are actually superior to SASS variables because you can change them at runtime via JS.
- kowdermeister 8y 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 8y 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 8y 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.
whoisjuan 8y ago
I honestly have never seen the value in pre-processors when writing CSS. I think they abstract a lot of low-level understanding of your UI and make your stylesheets overly complex. They definitely keep things sane when doing CSS at very large scale (for example dealing with color palettes, fonts, etc) but are not that useful when you're writing different components with different rendering needs. Nowadays I just do functional CSS (Tachyons, Tailwinds, Fractures, etc). It has some drawbacks but you can go faster and change things more atomically without breaking everything when changing a class, and you have the safety given by the fact that every property have the same level of specificity (which can be overriden by JS generated style attributes, in case you need to manipulate the DOM directly) Also, you can address your rendering needs atomically which works very nicely when you're writing components in isolation. They also are an excellent approach when doing server-side rendering since you can store classes combinations in variables that can be passed from one template to another or used and overriden in the same template as it gets evaluated by the server. It's almost like a pre-processor without the hassle of recompiling your sheets.
- nkozyra 8y ago
  > I honestly have never seen the value in pre-processors when writing CSS. As mentioned, theming and consistent ux requires far less writing and copy paste with a preprocessor than in pure CSS. I think React's approaches make CSS feel simpler but often just sweep the inefficiencies under the rug. A lot of this is being fixed with CSS4, so these will go the way of jQuery. And while you don't need jQuery today, it served as an important polyfill for a long time.
  - scrollaway 8y ago
    > A lot of this is being fixed with CSS4 CSS4 won't have nesting. SCSS isn't going away as long as nesting isn't a thing in native css. (Also css variables are awful to use. Honestly, CSS-WG should have just copied most of scss's syntax)
    - nkozyra 8y ago
      I agree about CSS variables. I'm unsure about the merits of nesting. Tends to make for some hard-to-read code.
Waterluvian 8y ago
I read somewhere a quote like, "a bad abstraction is worse than none at all." And for that I'm always on the lookout for things that look the same but aren't actually. Careful not to merge them via abstraction because they might deviate heavily all of a sudden and now you have to refactor a lot. CSS is the #1 place where I spot those cases. And I feel that Sass and other CSS preprocessors mostly lend themselves to shooting yourself in the foot with abstracting similar things that aren't actually of the same category.
- gitgud 8y ago
  Well said, creating good abstractions is hard and takes careful consideration. Hopefully the abstraction has some kind of benefit; simplicity, flexibility or extensibility. I've personally found SASS to be cumbersome with the encouraged nested of CSS and tightly couples the CSS to the DOM markup. A better abstraction in my opinion is a utility CSS library like Tailwind.css. It feels strange at first, but compose-able utility styles eventually feels like a good abstraction, with less shots to your feet.
  - type0 8y ago
    > A better abstraction in my opinion is a utility CSS library like Tailwind.css Exchanging sass with postcss based framework in my book is the worse abstraction for almost any purpose.
    - urbanjunkie 8y ago
      Your book is wrong. You are wrong. Educate yourself.
    - gitgud 8y ago
      Why is that? Have you used it for significant projects? I've found the hierarchy of CSS classes and where they're defined (e.g. global or component) become hard to to manage and refactor when you want to reshuffle components around... I feel postcss-based styling is simply more predictable and easier to refactor. And the abstraction, which can be clunky at first, becomes a sort of intuitive DSL which let's you develop faster...
ethhics 8y ago
Hi, undergrad here. That is to say, I’m not anything close to an expert in web design, but just in the course of making a simple static website to show recruiters I realized a lot of lessons like these about how modern HTML/CSS/JS can really handle anything you throw at it without having to worry about frameworks or precompilers. Sure, Bootstrap and SASS helped get a prototype up fast, but I feel like that gain in productivity was wasted once I had to fight the framework for the fine details, and just writing what I wanted in vanilla-land ended up writing out the frameworks as a byproduct. Is this a common pattern in industry as well?
- zdragnar 8y ago
  JS, no. A hand rolled framework is going to be a hindrance the more feature-ful your site becomes. OTOH, css frameworks go the other way. The more you have to do, the more apparent that bootstrap etc. get in your way, largely because css isn't a "complete" language. I know some few who swear by them, but the majority of people I know who did html/css exclusively for years feel they can write by hand anything they would want from bootstrap in less time than they would waste in fighting things like selector specificity and other inflexible choices. YMMV of course, and you can pry postcss + preset-env + mixins from my cold, dead hands.
- mjlangiii 8y ago
  It is a bit of catch-22 IMHO, for some. If you're very experienced it is just as easy to roll your own (although others may not onboard as quickly compared to well known libraries). If you're not very experienced then if you try to roll your own it may wind up being a mess. I'm in the middle and once I understand a library well I know its limitations and use its components as they were intended where I won't have to customize them too much, and roll my own components for the rest. This largely sidesteps the issues I used to have of wrestling with UI frameworks. I hope that helps.
  - ethhics 8y ago
    Certainly! I wanted to hear some viewpoints about full vanilla vs framework-based development, and your view of grokking the tools and implementing what it doesn’t cover is a great one to consider.
notjustanymike 8y ago
Everyone forgets that SASS is meant to be programmable CSS. It has loops, functions, namespacing, arrays, maps, and tons of utility functions (especially around color). If you treat it as CSS+ then you're not really benefitting from it's true potential.
- jcr1488 8y ago
  > Everyone forgets that SASS is meant to be programmable CSS That sounds like a solution looking for a problem... The vast majority of real SASS I've seen has been much like the stuff this article mentions. > If you treat it as CSS+ then you're not really benefitting from it's true potential People aren't looking for "potential", they're looking for a way to accomplish their design goals whilst keeping their stylesheets maintainable. The real use cases where SASS is actually worth the complexity overheads are getting fewer and fewer.
_bxg1 8y ago
The only thing I still couldn't live without is nested selectors. Writing maintainable CSS at scale is impossible without them. I really wonder why they haven't been made native yet.
- digianarchist 8y ago
  PostCSS [0] can do this and is far easier to install. https://github.com/postcss/postcss-nested https://github.com/postcss/postcss-nested
  - _bxg1 8y ago
    Not sure how the install could be easier than "get a single command line tool and run it against your root source file". If you're talking about the Ruby version, node-sass doesn't require any of those extra steps
    - digianarchist 8y ago
      Have you ever tried to get libsass installed on a CI server? Painful.
      - _bxg1 8y ago
        Nope, though you're generally supposed to use a project that uses libsass (of which there are many), not use it directly. If the issue is the binary itself, then maybe the Ruby version is what you want after all.
        digianarchist 8y ago
        That's not the point. Installing via a library is actually worse. NPM will bypass proxy settings via the postinstall script. My point is that the libsass library should be ported to WASM to ease the installation in a CI environment.
- BigJono 8y ago
deleted 8y ago
[deleted]
jheriko 8y ago
Hello "human centered designer, specialising in interaction design, HTML & CSS" Your font is too big.
- seppin 8y ago
  Everything else v awkward as well
namelosw 8y ago
The biggest thing Sass annoys me is in Node.js environment, I have to choose either node-sass which depends on native module which require extra compilation or matched pre-built binary. Or I have to choose ruby-sass which depends on a global installation of Ruby. Both of the options are brittle. For SPA I found it's easier to use CSS-in-JS solution like styled-component or emotion. Or for Typescript I just use typestyle. For non SPA I usually go vanilla CSS for simple stuff and stylus for complex stuff.
- arvinsim 8y ago
  > For SPA I found it's easier to use CSS-in-JS solution like styled-component or emotion. Or for Typescript I just use typestyle. Heck, even CSS modules is enough.
  - namelosw 8y ago
    Yes, CSS modules is pretty good. But most of the CSS-in-JS solutions could let me omit an extra loader since they're just JS.
jayshua 8y ago
I recently built a new website from scratch after about three years working in other software areas. Found to my surprise that I came back with some very different opinions about how CSS should be structured than I had in my web dev days, and I didn't end up using SASS at all. Still think the code ended up cleaner and more modular than what I wrote before using SASS. The only feature I really missed was @extend, but making the code I would have put in the % selector an actual class and using that in addition to a specialization class in the HTML worked well enough.
kbody 8y ago
I'm quite surprised by the number of comments on Sass/CSS pre-processors being of little to no value while we have created a huge complicated Frankenstein mess with webpack/React and the rest.
- throwaway66666 8y ago
  I am quite surprised at how the wheels have turned. I remember a year ago I was interviewing people and each single candidate listed SASS as a skill, and almost everyone during the interview claimed its their preferred method of working. (my team so far has been using plain css and are happy with it, so that surprised me a lot back then). Is it considered bad practice now? How did it rise so quickly, how did it fall so quickly, what's going on in the web dev world?
  - brink 8y ago
    Web developers have a long history of doing it just because they can, not necessarily because they should.
  - everdev 8y ago
    Sass and other CSS generators were useful a few years ago for rapid code generation. However, CSS has caught up as have editors and it's hard to see what real advantage Sass has today. Some novel things like a primaryColor variable to easily adust your theme is easily replicated with a traditional find/replace. The fewer frameworks / compiles-to X languages you have to learn the better. IMO, a little redundancy is better than a little complexity or a little dependency.
    - agge 8y ago
      Sass is very much still useful today. Mixins, used sparsely, can be very powerful and avoid large doses of redundancy. Also variables with good names make the job a lot easier than communicating around hexvalues.
      - denisw 8y ago
actionowl 8y ago
I need more coffee, I misread "Sass" as "SaaS" until several sentences in... > I also unintentionally, (at least at first) removed all traces of Sass from my codebase. Especially this part, still thinking that was "SaaS" :)
luckylion 8y ago
What I really love about sass is using https://include-media.com/ https://include-media.com/ I hate writing media queries, but @include media("<desktop", ">tablet") { } Takes most of the pain away.
dfabulich 8y ago
A lot of folks here are saying that they couldn't live without nesting CSS selectors. FYI the CSS Working Group approved a working draft of native CSS Nesting last month; it's in "stage 1." https://drafts.csswg.org/css-nesting-1/ https://drafts.csswg.org/css-nesting-1/ There's a PostCSS polyfill you can use for it today. https://github.com/jonathantneal/postcss-nesting https://github.com/jonathantneal/postcss-nesting
- stefanfisk 8y ago
  when I use sass nesting it's almost always to do BEM style selectors via `&-`, which really is soo much easier to read than having to type the full selector every time, especially when you have A LOT of components in a directory structure. sadly this use case seems to be missing from the coming spec :(
  - somefuckingguy 8y ago
    Agreed. This is trivial to add if you use postcss (postcss-nested)
    - type0 8y ago
      Correct me if i'm wrong but postcss is js or node.js only, where's sass is trivial to add with any language.
      - MarvelousWololo 8y ago
        I'm not totally sure but I think that for Sass only you'd still need Ruby or Node.
        serial_dev 8y ago
        Sass has LibSass which is a C++ port of the Sass engine (which was originally written in Ruby). There are wrappers available in many languages, such as Go, Java, Node, PHP (and even Ruby, interestingly enough). https://sass-lang.com/libsass https://sass-lang.com/libsass
topicseed 8y ago
Worked a lot with CSS for 10+ years and SaaS' nesting is amazing. I still have no clue when to NOT nest, but oh well, it is so useful to componentize the stylesheets.
- kangoo1707 8y ago
  Nesting is okay for one-level. However it violates the principle of least astonishment. How come a button inside .header differs from the button inside a .footer, then where are the differences defined, inside the button.scss or header.scss? Then one must take into consideration CSS Specifility and sprinkle !important everywhere. Instead, use modifier (in BEM) or create two buttons (.header-button and .footer-button) or create 2 utility class (.is-header-btn, .is-footer-btn) or just use TailwindCSS and you're good to go for all kinds of requirements, without ever resort to !important
  - luckylion 8y ago
    > However it violates the principle of least astonishment. How come a button inside .header differs from the button inside a .footer, then where are the differences defined, inside the button.scss or header.scss? Then one must take into consideration CSS Specifility and sprinkle !important everywhere. That's true. On the other hand, who is still trying to figure those things out without using their browser's dev tools and source maps? Using Sass also doesn't mean that you can't use two button classes or utility classes.
  - topicseed 8y ago
    Yep, makes a lot of sense. I usually follow these guidelines but with larger "code as you go" projects, it gets a tad dirty. Chrome Dev Tools help to find what's glitchy when styling misbehaves.
benfrain 8y ago
Pedantic point. It’s ‘Sass’ and not ‘SASS’. Sass certainly pushed things forward in CSS world. Without Sass and LESS, Stylus et al. I am quite certain we wouldn’t have CSS custom properties and colour functions. Great additions to the language. That said, I left Sass specifically some years ago. https://benfrain.com/breaking-up-with-sass-postcss/ https://benfrain.com/breaking-up-with-sass-postcss/ Tangentially related — in terms of dealing with CSS tooling/output for large projects with many devs I have found the PostCSS ecosystem indispensable. I wrote this a few years back after setting things up with PostCSS at bet365.com this way: http://ecss.io/chapter9.html http://ecss.io/chapter9.html The good thing about PostCSS is you can reduce the features as CSS becomes more capable and easily incorporate extra tooling like autoprefixer.
bbx 8y ago
The case for CSS variables is interesting. I'm still trying to figure out the best way to integrate them with a CSS framework I created, called Bulma: https://bulma.io/ https://bulma.io/ There's a few ways to combine Sass variables and CSS variables: - make all Sass variables available as CSS variables as well, so $primary will also exist as --primary - assign a CSS variable to a Sass one: $primary: var(--red) - assign a Sass variable that was defined as a CSS one: $red: var(--red) and then $primary: $red Color functions are one aspect that isn't well supported yet by CSS only. There's also a more "philosophical" question: why offload the variable resolution to the client side when it can be done at compilation time? If you're not gonna update a variable's value at runtime, it doesn't really need to be available as a CSS variable. It's like single page apps that always render the same content, and are better off rendered once on the server side and delivered as static HTML, instead of being rendered thousands of times by each client. But to be fair, CSS variables have other benefits, like creating color variations very quickly: // Sass .is-success background-color: $green-invert border-color: $green color: $green &:hover background-color: $green border-color: $green-invert color: $green-invert &:active background-color: $green border-color: $green color: $green-invert // CSS .is-success --color: var(--success) --invert: var(--successInvert) Even with CSS variables, Sass still has a lot of benefits listed by other commenters here, like reusable mixins and nesting. And one of my favourites: @extend!
- seibelj 8y ago
  I just want to say thank you for bulma, it is a top notch project and I recommend it to everyone.
- Theodores 8y ago
  > why offload the variable resolution to the client side when it can be done at compilation time? Imagine I have a property that I need to change depending on screen resolution in order to make a responsive layout. In my CSS rule I specify it to have a fallback default and to take a CSS variable that over-rides it. Elsewhere in my CSS I define the CSS variable with a media query. The CSS rule is quite clear in that it shows that something changes or can change. In the olden days I would be declaring the CSS rule twice. Once for the default and once inside the media query. With the old fashioned approach it would not be clear looking at the CSS rule that it had an over-ride somewhere else in a media query. By using the CSS variable with a fallback in just the one rule I know that something in the rule changes. I can easily find the CSS variable, regardless of how it has been scoped to see what makes it get set. Since I know the convention for most of the CSS in the stylesheet, e.g. mobile first, I can guess that the variable is for the desktop setting. The advantage is that I have code that I can hand on to the next guy and feel happy that even if they are not yet up to speed on CSS variables they will be able to easily work out what is going on with individual rules. There is no point in Sass variables now, they are defunct. All of the functionality is superseded and there is no point learning two ways to achieve the same task when you can just master one. This trumps any 'compilation' speed ups, resolving variables is something that does not slow page load times. The only use case for not using CSS variables is if you have to support people using extremely old browser.
bovermyer 8y ago
Interesting. CSS has certainly come a long way. I'll still use Sass for the convenience of nested selectors, though.

211 points by spking 8y ago

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 8y 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 8y 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 8y ago
    You mean variables? Because I've seen sass refactors go just as badly.
baroffoos 8y 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 8y 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 8y 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 8y 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 8y ago
    How come I haven't experienced these downsides?
    - andykx 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y ago
  Use sassc and call it from your makefile.
  - jayshua 8y 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 8y ago
CSS variables are actually superior to SASS variables because you can change them at runtime via JS.
kowdermeister 8y 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 8y 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 8y 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.

whoisjuan 8y ago

I honestly have never seen the value in pre-processors when writing CSS. I think they abstract a lot of low-level understanding of your UI and make your stylesheets overly complex. They definitely keep things sane when doing CSS at very large scale (for example dealing with color palettes, fonts, etc) but are not that useful when you're writing different components with different rendering needs. Nowadays I just do functional CSS (Tachyons, Tailwinds, Fractures, etc). It has some drawbacks but you can go faster and change things more atomically without breaking everything when changing a class, and you have the safety given by the fact that every property have the same level of specificity (which can be overriden by JS generated style attributes, in case you need to manipulate the DOM directly) Also, you can address your rendering needs atomically which works very nicely when you're writing components in isolation. They also are an excellent approach when doing server-side rendering since you can store classes combinations in variables that can be passed from one template to another or used and overriden in the same template as it gets evaluated by the server. It's almost like a pre-processor without the hassle of recompiling your sheets.

nkozyra 8y ago
> I honestly have never seen the value in pre-processors when writing CSS. As mentioned, theming and consistent ux requires far less writing and copy paste with a preprocessor than in pure CSS. I think React's approaches make CSS feel simpler but often just sweep the inefficiencies under the rug. A lot of this is being fixed with CSS4, so these will go the way of jQuery. And while you don't need jQuery today, it served as an important polyfill for a long time.
- scrollaway 8y ago
  > A lot of this is being fixed with CSS4 CSS4 won't have nesting. SCSS isn't going away as long as nesting isn't a thing in native css. (Also css variables are awful to use. Honestly, CSS-WG should have just copied most of scss's syntax)
  - nkozyra 8y ago
    I agree about CSS variables. I'm unsure about the merits of nesting. Tends to make for some hard-to-read code.

Waterluvian 8y ago

I read somewhere a quote like, "a bad abstraction is worse than none at all." And for that I'm always on the lookout for things that look the same but aren't actually. Careful not to merge them via abstraction because they might deviate heavily all of a sudden and now you have to refactor a lot. CSS is the #1 place where I spot those cases. And I feel that Sass and other CSS preprocessors mostly lend themselves to shooting yourself in the foot with abstracting similar things that aren't actually of the same category.

gitgud 8y ago
Well said, creating good abstractions is hard and takes careful consideration. Hopefully the abstraction has some kind of benefit; simplicity, flexibility or extensibility. I've personally found SASS to be cumbersome with the encouraged nested of CSS and tightly couples the CSS to the DOM markup. A better abstraction in my opinion is a utility CSS library like Tailwind.css. It feels strange at first, but compose-able utility styles eventually feels like a good abstraction, with less shots to your feet.
- type0 8y ago
  > A better abstraction in my opinion is a utility CSS library like Tailwind.css Exchanging sass with postcss based framework in my book is the worse abstraction for almost any purpose.
  - urbanjunkie 8y ago
    Your book is wrong. You are wrong. Educate yourself.
  - gitgud 8y ago
    Why is that? Have you used it for significant projects? I've found the hierarchy of CSS classes and where they're defined (e.g. global or component) become hard to to manage and refactor when you want to reshuffle components around... I feel postcss-based styling is simply more predictable and easier to refactor. And the abstraction, which can be clunky at first, becomes a sort of intuitive DSL which let's you develop faster...

ethhics 8y ago

Hi, undergrad here. That is to say, I’m not anything close to an expert in web design, but just in the course of making a simple static website to show recruiters I realized a lot of lessons like these about how modern HTML/CSS/JS can really handle anything you throw at it without having to worry about frameworks or precompilers. Sure, Bootstrap and SASS helped get a prototype up fast, but I feel like that gain in productivity was wasted once I had to fight the framework for the fine details, and just writing what I wanted in vanilla-land ended up writing out the frameworks as a byproduct. Is this a common pattern in industry as well?

zdragnar 8y ago
JS, no. A hand rolled framework is going to be a hindrance the more feature-ful your site becomes. OTOH, css frameworks go the other way. The more you have to do, the more apparent that bootstrap etc. get in your way, largely because css isn't a "complete" language. I know some few who swear by them, but the majority of people I know who did html/css exclusively for years feel they can write by hand anything they would want from bootstrap in less time than they would waste in fighting things like selector specificity and other inflexible choices. YMMV of course, and you can pry postcss + preset-env + mixins from my cold, dead hands.
mjlangiii 8y ago
It is a bit of catch-22 IMHO, for some. If you're very experienced it is just as easy to roll your own (although others may not onboard as quickly compared to well known libraries). If you're not very experienced then if you try to roll your own it may wind up being a mess. I'm in the middle and once I understand a library well I know its limitations and use its components as they were intended where I won't have to customize them too much, and roll my own components for the rest. This largely sidesteps the issues I used to have of wrestling with UI frameworks. I hope that helps.
- ethhics 8y ago
  Certainly! I wanted to hear some viewpoints about full vanilla vs framework-based development, and your view of grokking the tools and implementing what it doesn’t cover is a great one to consider.

notjustanymike 8y ago

Everyone forgets that SASS is meant to be programmable CSS. It has loops, functions, namespacing, arrays, maps, and tons of utility functions (especially around color). If you treat it as CSS+ then you're not really benefitting from it's true potential.

jcr1488 8y ago
> Everyone forgets that SASS is meant to be programmable CSS That sounds like a solution looking for a problem... The vast majority of real SASS I've seen has been much like the stuff this article mentions. > If you treat it as CSS+ then you're not really benefitting from it's true potential People aren't looking for "potential", they're looking for a way to accomplish their design goals whilst keeping their stylesheets maintainable. The real use cases where SASS is actually worth the complexity overheads are getting fewer and fewer.

_bxg1 8y ago

The only thing I still couldn't live without is nested selectors. Writing maintainable CSS at scale is impossible without them. I really wonder why they haven't been made native yet.

digianarchist 8y ago
PostCSS [0] can do this and is far easier to install. https://github.com/postcss/postcss-nested https://github.com/postcss/postcss-nested
- _bxg1 8y ago
  Not sure how the install could be easier than "get a single command line tool and run it against your root source file". If you're talking about the Ruby version, node-sass doesn't require any of those extra steps
  - digianarchist 8y ago
    Have you ever tried to get libsass installed on a CI server? Painful.
    - _bxg1 8y ago
      Nope, though you're generally supposed to use a project that uses libsass (of which there are many), not use it directly. If the issue is the binary itself, then maybe the Ruby version is what you want after all.
      - digianarchist 8y ago
        That's not the point. Installing via a library is actually worse. NPM will bypass proxy settings via the postinstall script. My point is that the libsass library should be ported to WASM to ease the installation in a CI environment.
BigJono 8y ago

deleted 8y ago

[deleted]

jheriko 8y ago

Hello "human centered designer, specialising in interaction design, HTML & CSS" Your font is too big.

seppin 8y ago
Everything else v awkward as well

namelosw 8y ago

The biggest thing Sass annoys me is in Node.js environment, I have to choose either node-sass which depends on native module which require extra compilation or matched pre-built binary. Or I have to choose ruby-sass which depends on a global installation of Ruby. Both of the options are brittle. For SPA I found it's easier to use CSS-in-JS solution like styled-component or emotion. Or for Typescript I just use typestyle. For non SPA I usually go vanilla CSS for simple stuff and stylus for complex stuff.

arvinsim 8y ago
> For SPA I found it's easier to use CSS-in-JS solution like styled-component or emotion. Or for Typescript I just use typestyle. Heck, even CSS modules is enough.
- namelosw 8y ago
  Yes, CSS modules is pretty good. But most of the CSS-in-JS solutions could let me omit an extra loader since they're just JS.

jayshua 8y ago

I recently built a new website from scratch after about three years working in other software areas. Found to my surprise that I came back with some very different opinions about how CSS should be structured than I had in my web dev days, and I didn't end up using SASS at all. Still think the code ended up cleaner and more modular than what I wrote before using SASS. The only feature I really missed was @extend, but making the code I would have put in the % selector an actual class and using that in addition to a specialization class in the HTML worked well enough.

kbody 8y ago

I'm quite surprised by the number of comments on Sass/CSS pre-processors being of little to no value while we have created a huge complicated Frankenstein mess with webpack/React and the rest.

throwaway66666 8y ago
I am quite surprised at how the wheels have turned. I remember a year ago I was interviewing people and each single candidate listed SASS as a skill, and almost everyone during the interview claimed its their preferred method of working. (my team so far has been using plain css and are happy with it, so that surprised me a lot back then). Is it considered bad practice now? How did it rise so quickly, how did it fall so quickly, what's going on in the web dev world?
- brink 8y ago
  Web developers have a long history of doing it just because they can, not necessarily because they should.
- everdev 8y ago
  Sass and other CSS generators were useful a few years ago for rapid code generation. However, CSS has caught up as have editors and it's hard to see what real advantage Sass has today. Some novel things like a primaryColor variable to easily adust your theme is easily replicated with a traditional find/replace. The fewer frameworks / compiles-to X languages you have to learn the better. IMO, a little redundancy is better than a little complexity or a little dependency.
  - agge 8y ago
    Sass is very much still useful today. Mixins, used sparsely, can be very powerful and avoid large doses of redundancy. Also variables with good names make the job a lot easier than communicating around hexvalues.
    - denisw 8y ago

actionowl 8y ago

I need more coffee, I misread "Sass" as "SaaS" until several sentences in... > I also unintentionally, (at least at first) removed all traces of Sass from my codebase. Especially this part, still thinking that was "SaaS" :)

luckylion 8y ago

What I really love about sass is using https://include-media.com/ https://include-media.com/ I hate writing media queries, but @include media("<desktop", ">tablet") { } Takes most of the pain away.

dfabulich 8y ago

A lot of folks here are saying that they couldn't live without nesting CSS selectors. FYI the CSS Working Group approved a working draft of native CSS Nesting last month; it's in "stage 1." https://drafts.csswg.org/css-nesting-1/ https://drafts.csswg.org/css-nesting-1/ There's a PostCSS polyfill you can use for it today. https://github.com/jonathantneal/postcss-nesting https://github.com/jonathantneal/postcss-nesting

stefanfisk 8y ago
when I use sass nesting it's almost always to do BEM style selectors via `&-`, which really is soo much easier to read than having to type the full selector every time, especially when you have A LOT of components in a directory structure. sadly this use case seems to be missing from the coming spec :(
- somefuckingguy 8y ago
  Agreed. This is trivial to add if you use postcss (postcss-nested)
  - type0 8y ago
    Correct me if i'm wrong but postcss is js or node.js only, where's sass is trivial to add with any language.
    - MarvelousWololo 8y ago
      I'm not totally sure but I think that for Sass only you'd still need Ruby or Node.
      - serial_dev 8y ago
        Sass has LibSass which is a C++ port of the Sass engine (which was originally written in Ruby). There are wrappers available in many languages, such as Go, Java, Node, PHP (and even Ruby, interestingly enough). https://sass-lang.com/libsass https://sass-lang.com/libsass

topicseed 8y ago

Worked a lot with CSS for 10+ years and SaaS' nesting is amazing. I still have no clue when to NOT nest, but oh well, it is so useful to componentize the stylesheets.

kangoo1707 8y ago
Nesting is okay for one-level. However it violates the principle of least astonishment. How come a button inside .header differs from the button inside a .footer, then where are the differences defined, inside the button.scss or header.scss? Then one must take into consideration CSS Specifility and sprinkle !important everywhere. Instead, use modifier (in BEM) or create two buttons (.header-button and .footer-button) or create 2 utility class (.is-header-btn, .is-footer-btn) or just use TailwindCSS and you're good to go for all kinds of requirements, without ever resort to !important
- luckylion 8y ago
  > However it violates the principle of least astonishment. How come a button inside .header differs from the button inside a .footer, then where are the differences defined, inside the button.scss or header.scss? Then one must take into consideration CSS Specifility and sprinkle !important everywhere. That's true. On the other hand, who is still trying to figure those things out without using their browser's dev tools and source maps? Using Sass also doesn't mean that you can't use two button classes or utility classes.
- topicseed 8y ago
  Yep, makes a lot of sense. I usually follow these guidelines but with larger "code as you go" projects, it gets a tad dirty. Chrome Dev Tools help to find what's glitchy when styling misbehaves.

benfrain 8y ago

Pedantic point. It’s ‘Sass’ and not ‘SASS’. Sass certainly pushed things forward in CSS world. Without Sass and LESS, Stylus et al. I am quite certain we wouldn’t have CSS custom properties and colour functions. Great additions to the language. That said, I left Sass specifically some years ago. https://benfrain.com/breaking-up-with-sass-postcss/ https://benfrain.com/breaking-up-with-sass-postcss/ Tangentially related — in terms of dealing with CSS tooling/output for large projects with many devs I have found the PostCSS ecosystem indispensable. I wrote this a few years back after setting things up with PostCSS at bet365.com this way: http://ecss.io/chapter9.html http://ecss.io/chapter9.html The good thing about PostCSS is you can reduce the features as CSS becomes more capable and easily incorporate extra tooling like autoprefixer.

bbx 8y ago

The case for CSS variables is interesting. I'm still trying to figure out the best way to integrate them with a CSS framework I created, called Bulma: https://bulma.io/ https://bulma.io/ There's a few ways to combine Sass variables and CSS variables: - make all Sass variables available as CSS variables as well, so $primary will also exist as --primary - assign a CSS variable to a Sass one: $primary: var(--red) - assign a Sass variable that was defined as a CSS one: $red: var(--red) and then $primary: $red Color functions are one aspect that isn't well supported yet by CSS only. There's also a more "philosophical" question: why offload the variable resolution to the client side when it can be done at compilation time? If you're not gonna update a variable's value at runtime, it doesn't really need to be available as a CSS variable. It's like single page apps that always render the same content, and are better off rendered once on the server side and delivered as static HTML, instead of being rendered thousands of times by each client. But to be fair, CSS variables have other benefits, like creating color variations very quickly: // Sass .is-success background-color: $green-invert border-color: $green color: $green &:hover background-color: $green border-color: $green-invert color: $green-invert &:active background-color: $green border-color: $green color: $green-invert // CSS .is-success --color: var(--success) --invert: var(--successInvert) Even with CSS variables, Sass still has a lot of benefits listed by other commenters here, like reusable mixins and nesting. And one of my favourites: @extend!

seibelj 8y ago
I just want to say thank you for bulma, it is a top notch project and I recommend it to everyone.
Theodores 8y ago
> why offload the variable resolution to the client side when it can be done at compilation time? Imagine I have a property that I need to change depending on screen resolution in order to make a responsive layout. In my CSS rule I specify it to have a fallback default and to take a CSS variable that over-rides it. Elsewhere in my CSS I define the CSS variable with a media query. The CSS rule is quite clear in that it shows that something changes or can change. In the olden days I would be declaring the CSS rule twice. Once for the default and once inside the media query. With the old fashioned approach it would not be clear looking at the CSS rule that it had an over-ride somewhere else in a media query. By using the CSS variable with a fallback in just the one rule I know that something in the rule changes. I can easily find the CSS variable, regardless of how it has been scoped to see what makes it get set. Since I know the convention for most of the CSS in the stylesheet, e.g. mobile first, I can guess that the variable is for the desktop setting. The advantage is that I have code that I can hand on to the next guy and feel happy that even if they are not yet up to speed on CSS variables they will be able to easily work out what is going on with individual rules. There is no point in Sass variables now, they are defunct. All of the functionality is superseded and there is no point learning two ways to achieve the same task when you can just master one. This trumps any 'compilation' speed ups, resolving variables is something that does not slow page load times. The only use case for not using CSS variables is if you have to support people using extremely old browser.

bovermyer 8y ago

Interesting. CSS has certainly come a long way. I'll still use Sass for the convenience of nested selectors, though.