7 ms·

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 a

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.

agge 7y ago
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 7y ago
  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/--* https://developer.mozilla.org/en-US/docs/Web/CSS/--*
intertextuality 7y ago
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 7y ago
  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 7y ago
    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/ 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 7y ago
      > 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 7y ago
        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 7y ago
> 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 7y ago
  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 7y ago

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 7y ago
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/--* https://developer.mozilla.org/en-US/docs/Web/CSS/--*

intertextuality 7y ago

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 7y ago
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 7y ago
  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/ 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 7y ago
    > 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 7y ago
      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 7y ago

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