Live data from Hacker News

Stepping Away from Sass

cathydutton.co.uk

101–110 of 157 posts

Re: Stepping Away from Sass

#101
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/

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

The good thing about PostCSS is you can reduce the features as CSS becomes more capable and easily incorporate extra tooling like autoprefixer.

Re: Stepping Away from Sass

#102
post #58

Earlier quoted context omitted.

Most nesting I do uses the '&' parent selector, so it's not "real" nesting. .a-long-class-name { background: firebrick; &:hover { background: red; } } This approach has some clear benefits (less verbose and it groups related code together) with little or no downsides.

Same, but this can definitely get long, ala & > div, & a, & a { &:hover } etc.

The solution is to not write css like this... ;)

Re: Stepping Away from Sass

#103
post #57

Earlier quoted context omitted.

You're right, on OSX you can brew install sassc

there's a Debian package :) thanks for the tip :)

just got this working with fswatch and sassc, thought I'd feed back that this is perfect, thanks :)

Re: Stepping Away from Sass

#104
post #96

Earlier quoted context omitted.

>>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, whic…

I find that https://github.com/wellington/go-libsass is usually good enough for Go projects.

yeah, I looked at that, but a few things put me off (unmaintained, old version of scss, some caveats in the readme, etc).

Just got sassc working instead, so happy again hehe

Re: Stepping Away from Sass

#105

Earlier quoted context omitted.

useful, I didn't know about this. Thanks. How does the reporting of vulnerabilities work for npm? No, Golang doesn't, but then it doesn't have a registry like npm in the first place. Gophers tend not to use third-party libraries if at all possible.

isnt it very common to use github repositories as a library? I seem to recall that this was the way to get libraries, though it has been a few years since I looked into go

yes, but there's not an actual "registry" as such. Just a bunch of sites that have "useful go library" links.

Re: Stepping Away from Sass

#106

Earlier quoted context omitted.

useful, I didn't know about this. Thanks. How does the reporting of vulnerabilities work for npm? No, Golang doesn't, but then it doesn't have a registry like npm in the first place. Gophers tend not to use third-party libraries if at all possible.

> Gophers tend not to use third-party libraries if at all possible. That sounds weird to me. It's pretty rare (almost never?) for applications to do useful things without third party libraries. eg any database access, input validation, making sure HTML output isn't malicious, etc. Maybe that's just me though?

Go has an awesome standard library that does most stuff.

There's also a set of "semi-official" libraries for things like crypto that can't be written by amateurs ;)

There are some other libraries that are commonly used, but you can count them on one hand.

I'm a massive convert to this. Instead of spending my time working out how to get two 3rd-party libraries to talk to each other, I spend my time writing domain-specific code. and my debugging time is spent in repo's that I have a hope of understanding because I wrote them ;)

It doesn't suit everyone, and there are frequent rants on golang forums about people not importing dependencies. But every gopher seems to go through the same journey, and end up at a place where they just write their own code rather than importing it.

Re: Stepping Away from Sass

#107
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/

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!

Re: Stepping Away from Sass

#108
post #22
post #8

Earlier quoted context omitted.

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

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.

I generally stick to only 1 level of nesting - I still find that really beneficial.

Re: Stepping Away from Sass

#109

Earlier quoted context omitted.

Nesting is bad, because moving any element would break your style. And there's also performance impact. I found scoped css like component or BEM just make sense, which only encourage you nest one level in block namespace.

BEM is just an awkward workaround for the lack of nesting. You’re manually creating nesting hierarchies and naming them (something a computer should be doing). And yes, the moment you move something, everything breaks. Because instead of moving/renaming just the parent selector you have to move/rename all the related child selectors.

No what I mean by move something I mean adjust HTML structure, and deeply nested stylesheet means less flexible code. You can move anything within a BEM block without breaking style, instead of couple the CSS and HTML structure, which doubles every change.

And BEM is a workaround of names pace, not nesting. Nesting is not what CSS lack of. Instead what CSS really lack for is basic abstraction like function (same as function component in react to HTML). Given CSS is basically similar to key value pair (data), a first class function model would solve most of the problems - reusing, encapsulation, abstraction etc.

Re: Stepping Away from Sass

#110
post #82
post #25

Earlier quoted context omitted.

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 */.

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.

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. :)
Post reply on HN