Hacker News Reader

Comment by throwaway66666 | Hacker News Reader

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?

View on HN

Web developers have a long history of doing it just because they can, not necessarily because they should.

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.

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.

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/--*

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.

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

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

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

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.

Reply on news.ycombinator.com