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.
Stepping Away from Sass
51–60 of 157 posts
Re: Stepping Away from Sass
#52Earlier quoted context omitted.
Um, okay. You raise a compelling point.
Sorry, I'll elaborate. These kind of sweeping statements are usually pretty obviously false. You can write anything cleanly at scale. Those MS-DOS sources that were released a while back are pleasant enough to read despite being in assembly.
The implied meaning of "impossible" in this kind of context is "unreasonably difficult". Just as it would be unreasonably difficult to write modern Windows in assembly, it would be unreasonably difficult to maintain a large CSS codebase without nested selectors.
Re: Stepping Away from Sass
#53The only thing I still couldn't live without is nested selectors. Writing maintainable CSS at scale is impossible without them. I really wonder why they haven't been made native yet.
> The only thing I still couldn't live without is nested selectors. Writing maintainable CSS at scale is impossible without them. Bullshit.
"This hard and annoying thing you experience isn't really hard and annoying, and you should learn to do it the hard and annoying way. It really isn't hard and annoying, and if it is, I like it being hard and annoying anyway. I had to learn it the hard and annoying way, so why shouldn't the kids?"
This attitude is strangely pervasive on Hacker News, and it's very annoying.
Last time I posted about database migrations (a topic I've written fairly popular tools for and presented on) I was confidently told by a commenter: "Database migrations aren't hard. Simply write change scripts manually and apply them."
Re: Stepping Away from Sass
#54The only thing I still couldn't live without is nested selectors. Writing maintainable CSS at scale is impossible without them. I really wonder why they haven't been made native yet.
PostCSS [0] can do this and is far easier to install. https://github.com/postcss/postcss-nested
Not sure how the install could be easier than "get a single command line tool and run it against your root source file". If you're talking about the Ruby version, node-sass doesn't require any of those extra steps
Re: Stepping Away from Sass
#55I'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.
I am quite surprised at how the wheels have turned. I remember a year ago I was interviewing people and each single candidate listed SASS as a skill, and almost everyone during the interview claimed its their preferred method of working. (my team so far has been using plain css and are happy with it, so that surprised me a lot back then).
Is it considered bad practice now? How did it rise so quickly, how did it fall so quickly, what's going on in the web dev world?
Re: Stepping Away from Sass
#56Earlier 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.
Most nesting I do uses the '&' parent selector, so it's not "real" nesting.
.a-long-class-name {
background: firebrick;
&:hover {
background: red;
}
}
Re: Stepping Away from Sass
#57Re: Stepping Away from Sass
#58Earlier quoted context omitted.
I agree about CSS variables. I'm unsure about the merits of nesting. Tends to make for some hard-to-read code.
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.
Re: Stepping Away from Sass
#59I'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.
I am quite surprised at how the wheels have turned. I remember a year ago I was interviewing people and each single candidate listed SASS as a skill, and almost everyone during the interview claimed its their preferred method of working. (my team so far has been using plain css and are happy with it, so that surprised me a lot back then). Is it considered bad practice now? How did it rise so quickly, how did it fall…
Web developers have a long history of doing it just because they can, not necessarily because they should.
Re: Stepping Away from Sass
#60I'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.
I am quite surprised at how the wheels have turned. I remember a year ago I was interviewing people and each single candidate listed SASS as a skill, and almost everyone during the interview claimed its their preferred method of working. (my team so far has been using plain css and are happy with it, so that surprised me a lot back then). Is it considered bad practice now? How did it rise so quickly, how did it fall…
Sass and other CSS generators were useful a few years ago for rapid code generation. However, CSS has caught up as have editors and it's hard to see what real advantage Sass has today.
Some novel things like a primaryColor variable to easily adust your theme is easily replicated with a traditional find/replace.
The fewer frameworks / compiles-to X languages you have to learn the better.
IMO, a little redundancy is better than a little complexity or a little dependency.