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.
Stepping Away from Sass
31–40 of 157 posts
Re: Stepping Away from Sass
#32Earlier 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.
Re: Stepping Away from Sass
#33For 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
#34Earlier 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?
Re: Stepping Away from Sass
#35Earlier 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?
Re: Stepping Away from Sass
#36Does 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…
Re: Stepping Away from Sass
#37Earlier 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.
Re: Stepping Away from Sass
#38Earlier 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.
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
#39Earlier 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'm unsure about the merits of nesting. Tends to make for some hard-to-read code.
Re: Stepping Away from Sass
#40Earlier 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.