[everdev]

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.

[intertextuality]

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’m confused why sass of all things is an issue. It’s basically css, and very lightweight. You just add one step in your preferred build tool to transpile sass -> css. “vanilla is magically better” is not an argument.

[everdev]

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.

[intertextuality]

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.

[boomlinde]

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

[intertextuality]

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.

[arvinsim]

> Some novel things like a primaryColor variable to easily adust your theme is easily replicated with a traditional find/replace.

Any self respecting programmer will find this "solution" abhorrent and inelegant.

[everdev]

Some would say adding a dependency that doesn't give you anything new you can't already easily do is abhorrent and inelegant.

There's a trend to throw a library at the problem, but that comes at a cost.

[agge]

Sass is very much still useful today. Mixins, used sparsely, can be very powerful and avoid large doses of redundancy. Also variables with good names make the job a lot easier than communicating around hexvalues.

[denisw]

Variables alone are not a reason to use Sass anymore. There are CSS Custom Properties [1] now, which are even more powerful in that you can dynamically override them in specific sub-sections of the DOM. The only downside is that Internet Explorer 11 doesn't support them (if that's important for your target audience).

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/--*