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.
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, which compiles the scss to css. But that requires node.js, and npm (there are golang scss compilers, but all of them are either not being maintained, or have problems, or only support older versions of scss). I have to run this in a separate terminal so I can stop it when I need to.
I've deliberately not looked at my global node_modules directory. If I don't look, I don't have to worry about how many js libraries just got installed on my machine, and I don't have to think about who's maintaining them, and if they're now malicious. As long as sass only touches the css files, and css isn't Turing-complete (yet), then I don't need to audit any of that, and I can assume that it's not injecting malicious code into my application.
Though there are possible attacks on my site that could originate with code injection from a $malicious_left_pad js library, even via css, but it's enough of a stretch that my paranoia can live with it. I can check out the compressed css every now and again and see that it's not importing anything it shouldn't, and be reasonably sure that I haven't just compromised all my users' security.
So yeah, it's not so much that a preprocessor is a complication, it's that a preprocessor allows a malicious package to compile whatever it likes into files that I will then serve from my domain to my users, who trust that I'm not serving them malicious files. That's policed not at all by npm, or any of the package managers, who cheerfully assume that all javascript developers are honest.
SassC is just a cli tool that uses the C-language SASS library. It's an alternative to using whatever ridiculous NodeJS solution was/is being used.
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?
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.
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?
There's also a set of "semi-official" libraries for things like crypto that can't be written by amateurs ;)
There are some other libraries that are commonly used, but you can count them on one hand.
I'm a massive convert to this. Instead of spending my time working out how to get two 3rd-party libraries to talk to each other, I spend my time writing domain-specific code. and my debugging time is spent in repo's that I have a hope of understanding because I wrote them ;)
It doesn't suit everyone, and there are frequent rants on golang forums about people not importing dependencies. But every gopher seems to go through the same journey, and end up at a place where they just write their own code rather than importing it.
Just got sassc working instead, so happy again hehe
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.).
I just feel that nesting (which Sass encourages) leads to complexity and fragility.
Assuming you're using a component framework like React, Vue, or Angular (and not a shadow dom based system like Polymer), how do you isolate your component CSS?
When I make a component 'MyComponent', I give it the className 'MyComponent'. Then I can create a SCSS file and scope its entire contents:
.MyComponent {
// all the css specific to MyComponent
}
In Vue and Angular component styles are automatically encapsulated at the component level by scoping (I think) so nesting isn't really necessary to target specific components. Angular also recently deprecated a method of breaking out of component styling and soon it will be completely removed from the framework.
Although I'm a critic I'm not totally against nesting, I just feel that SASS encourages it, so without discipline things can get very complex and fragile. One level of nesting is OK with me though I suppose...
In what way(s) is SASS different than anything else in this regard?
These solutions all seem quite a lot more complicated than nested scopes! And at least for styled components (angular, I presume) and styled-jsx (react), they're framework-specific. Why are these solutions better?
I found scoped css like component or BEM just make sense, which only encourage you nest one level in block namespace.
https://stackoverflow.com/questions/13829959/nested-selector...
It's about Less but the same rule applies to CSS and Sass.
You’re manually creating nesting hierarchies and naming them (something a computer should be doing).
And yes, the moment you move something, everything breaks. Because instead of moving/renaming just the parent selector you have to move/rename all the related child selectors.
And BEM is a workaround of names pace, not nesting. Nesting is not what CSS lack of. Instead what CSS really lack for is basic abstraction like function (same as function component in react to HTML). Given CSS is basically similar to key value pair (data), a first class function model would solve most of the problems - reusing, encapsulation, abstraction etc.
In some cases I can preclude the necessity of having to declare class names.
section {
h1 {},
p {},
img {},In other cases I have an index with easy-to-find classes.
.hero {
.gradient {},
.description {},
.signup {},EDIT: I meant to reply to a different comment but oh well.
Is there another kind of CSS?
Terminology is important but I see it's not important among some people and other hobbyists online.
There is a meme within the community about 'vanilla JavaScript' called VanillaJS:
https://stackoverflow.com/questions/20435653/what-is-vanilla...
The overwhelming majority of front-end projects and developers that I encounter use some kind of library, framework, or compilation/build tool. It's common enough to basically be the default.
If you use 'plain' or 'vanilla' javascript (or CSS), you're doing something less common, at the very least around these parts, and so qualifying this makes sense. The mere fact that many people clearly seem to feel a need to point this out makes it so. Why would they otherwise?
Judging by your comment history, the vast majority of your contributions here boil down to some kind of dig at how 'people these days' are 'doing it wrong', and how obviously you are superior to that and how you don't see the need for any of this new-fangled stuff. I'm honestly curious whether that's just role-playing, or if that kind of superiority about being older and wiser is somehow important to you.
I'd very much prefer it if you shared the wisdom you've accrued in a more constructive way, because as far as I can tell you're not actually wrong about a lot of this stuff.
Older and wiser curmudgeons have played a valuable role in my development, but your approach strikes me as self-serving and somewhat poisonous to the/any community. But of course you're free to do as you please.
https://stackoverflow.com/a/40115909/135845
Unfortunately, I see that "The Ubuntu Web Team" decided to shit the bed and steal the name for the CSS framework they created. So fsck me I guess.
* Duplicating the effect of mixins by just... having another css class for the mixed-in stuff works well enough for many cases (though this hurts most where you're trying for semantic selector naming conventions, with mixins adding in rulesets behind the scenes).
* Nesting selectors save thinking and some typing regarding where styles cascade out to, but... tbh, yanking a high-resolution selector into the buffer and chucking it out onto another line was never a burdensome part of my pre- processor workflow.
* Pretty sure free-use of nested selectors and mixins is trading larger CSS files for developer attention (which may or may not be a valid trade).
* Variables... yeah, they're handy. Search-and-replace only goes so far. IE seems to be the holdup.
For small or disciplined teams with the freedom & skill to really think about their CSS starting from a style-guide-first perspective rather than every-page-a-custom-layout perspective, I can see making the choice to do without. Especially if you've already ditched IE 11 support for other reasons.
Where SASS shines is when you need to do a coordinated change, e.g. these things become gray instead of black. You have a ton of black things so no search and replace. And once you've painstakingly determined and edited the classes, the hard part is to be sure that you only changed what you had to, and nothing unrelated.
SASS preserves semantics which plain CSS is unable to express. It's like C vs assembly.
Because I've seen sass refactors go just as badly.
My personal solution to avoid running watchers is to have a run-on-save task in VSCode that automatically compiles any "root" .scss file (eg */index.scss) into a .css file with an accompanying .css.map file.
I still love SASS since it solves many existing problems at once like you mentioned.
They also aren't a full sass/less replacement, just one aspect
In a corporate environment, too, you need to proxy many of these, and set an environmental variable in the shell for SASS to install properly. Over time, this adds significant cost, pain, and stress to the install process.