Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stepping Away from Sass

cathydutton.co.uk

Post reply on HN
Print view View original

81–90 of 157 posts

Re: Stepping Away from Sass

#81

Post by kowdermeister »

statictype wrote: post #2

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.

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.

Re: Stepping Away from Sass

#82

Post by tobr »

baddox wrote: post #25
statictype wrote: post #2

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.

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.

Re: Stepping Away from Sass

#83

Post by intertextuality »

everdev wrote: post #79
intertextuality wrote: post #70

Earlier quoted context omitted.

Using a find and replace instead of a variable holder is extremely bad practice. I should not have to copy/paste my site’s brand colors every time. The original reason I switched was for nested structures so I could stop repeating myself. E.g. div { &:hover {} .class ul {} } This made it much more pleasant to write in sass. The other thing is mixins. If vanilla css doesn’t support this then it’s still a no-go. Lastly…

I used to write only in Sass for these same reasons, but switched back to CSS. CSS now has variables (if you really need them -- chances are you don't). The redundancy of writing a selector multiple times is sightly annoying, but I don't think it rises to the level of value I need to include a new dependency in my app or build pipeline.

That still doesn't account for mixins, which turn out to be very handy. Some examples here.[0]

[0]: https://css-tricks.com/custom-user-mixins/

These are preferable because you can compose them as needed for elements, instead of having to make extra classes.

> CSS now has variables (if you really need them -- chances are you don't).

I fail to see how you could -not- need variables. Not many, mind you, but using none at all boggles the mind. For starters, DRY code is fairly fundamental. When you update a referenced variable you only need to do it in 1 place. Relying on "find and replace" leads to "oops I accidentally missed one, now we have a bug that could have been totally avoided".

It also helps with consistency for site theming/branding. You can define $primaryColor, $primaryHighlight, $secondaryColor, $textColor, $backgroundColor, etc, and reference these down the line instead of copy/pasting and getting bugs if the specs change.

Re: Stepping Away from Sass

#84

Post by dfabulich »

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/

There's a PostCSS polyfill you can use for it today. https://github.com/jonathantneal/postcss-nesting

Re: Stepping Away from Sass

#85

Post by justinclift »

marcus_holmes wrote: post #63
yawaramin wrote: post #43

Earlier quoted context omitted.

> I can assume that it's not injecting malicious code into my application. You don't need to assume, npm has an audit command that helps figure out if any of your package dependencies have reported vulnerabilities: https://docs.npmjs.com/cli/audit Does Go?

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?

Re: Stepping Away from Sass

#86

Post by mercer »

BigJono wrote: post #41
pixelbash wrote: post #35

Earlier quoted context omitted.

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.

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.

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

Re: Stepping Away from Sass

#88

Post by dmitriid »

nkozyra wrote: post #39
scrollaway wrote: post #12

Earlier quoted context omitted.

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

Compared to BEM's .b-text-input__text-field or .b-select__option_selected or .media__img--rev nesting is a concise readable breath of fresh air

Re: Stepping Away from Sass

#89

Post by stefanfisk »

dfabulich wrote: post #84

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/ There's a PostCSS polyfill you can use for it today. https://github.com/jonathantneal/postcss-nesting

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 :(

Re: Stepping Away from Sass

#90

Post by somefuckingguy »

stefanfisk wrote: post #89
dfabulich wrote: post #84

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/ There's a PostCSS polyfill you can use for it today. https://github.com/jonathantneal/postcss-nesting

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 :(

Agreed. This is trivial to add if you use postcss (postcss-nested)
Post reply on HN