Live data from Hacker News

Stepping Away from Sass

cathydutton.co.uk

31–40 of 157 posts

Re: Stepping Away from Sass

#31

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.

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

Re: Stepping Away from Sass

#32
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.

How come I haven't experienced these downsides?

Re: Stepping Away from Sass

#33
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.

Re: Stepping Away from Sass

#34
post #32
post #22

Earlier quoted context omitted.

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.

How come I haven't experienced these downsides?

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.

Re: Stepping Away from Sass

#35
post #32
post #22

Earlier quoted context omitted.

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.

How come I haven't experienced these downsides?

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.

Re: Stepping Away from Sass

#36

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.

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

Use sassc and call it from your makefile.

Re: Stepping Away from Sass

#37
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.

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.

There's no performance impact. Styles are precompiled locally before deployment.

Re: Stepping Away from Sass

#38

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.

There's no performance impact. Styles are precompiled locally before deployment.

There is, at runtime browser needs to do extra matching.

https://stackoverflow.com/questions/13829959/nested-selector...

It's about Less but the same rule applies to CSS and Sass.

Re: Stepping Away from Sass

#39
post #7

Earlier quoted context omitted.

> 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 serv…

> 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)

I agree about CSS variables.

I'm unsure about the merits of nesting. Tends to make for some hard-to-read code.

Re: Stepping Away from Sass

#40

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…

Use sassc and call it from your makefile.

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