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

91–100 of 157 posts

Re: Stepping Away from Sass

#91

Post by kangoo1707 »

topicseed wrote: post #87

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.

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

Re: Stepping Away from Sass

#92

Post by speleding »

marcus_holmes wrote: post #29
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.

>>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've been using the ruby Sass gem instead of the NPM version (https://sass-lang.com/ruby-sass). That prevents having to do the whole node thing. I know they say the ruby version is in maintenance mode, but for 99% of the use cases that's fine, it's been battle tested for years and Sass doesn't change that often anymore.

Re: Stepping Away from Sass

#93

Post by boomlinde »

intertextuality wrote: post #83
everdev wrote: post #79

Earlier quoted context omitted.

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

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

Isn't that the point of selecting classes in the first place? That said, I understand the utility in using it for things like individual colors, as you described.

Re: Stepping Away from Sass

#94

Post by luckylion »

kangoo1707 wrote: post #91
topicseed wrote: post #87

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.

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

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

Re: Stepping Away from Sass

#95

Post by intertextuality »

boomlinde wrote: post #93
intertextuality wrote: post #83

Earlier quoted context omitted.

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

> 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". Isn't that the point of selecting classes in the first place? That said, I understand the utility in using it for things like individual colors, as you described.

Classes do suffice if you follow the convention of "small, atom-like css classes". I personally hate this style and prefer compositional css classes for a component or a structured object.

Re: Stepping Away from Sass

#96

Post by type0 »

marcus_holmes wrote: post #29
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.

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

Re: Stepping Away from Sass

#97

Post by type0 »

gitgud wrote: post #22
rhizome wrote: 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.

As with everything, don't overdo it and you'll be fine.

Re: Stepping Away from Sass

#98

Post by type0 »

somefuckingguy wrote: post #90
stefanfisk wrote: post #89

Earlier quoted context omitted.

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)

Correct me if i'm wrong but postcss is js or node.js only, where's sass is trivial to add with any language.

Re: Stepping Away from Sass

#99

Post by type0 »

gitgud wrote: post #21
Waterluvian wrote: post #9

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

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

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

Re: Stepping Away from Sass

#100

Post by type0 »

jaredklewis wrote: post #73
kbody wrote: post #51

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.

Yea, webpack sure is horrible. Not like C/C++ programs, where we have a super simple setup of Make, config, and autoconf. Like checkout this easy-peasy Make file: https://github.com/apache/httpd/blob/trunk/Makefile.in . Even a child could understand it. Or look at Java. Who has ever seen a complicated ant or pom file? No one ever. This Lucene ant file practically wrote itself: https://github.com/apache/lucene-solr/bl…

> People like to shit on webpack, but I don't get it. It's a well thought out tool that works extremely well.

The problem isn't that webpack is bad but too many projects use it where there's not need for it. Also for newcomers to the js world it looks terrifyingly complicated. Sure those bootcamp rookies eventually discover how terrible C++ buils are but who cares since this is more like comparing a spoon with a shovel.

Post reply on HN