Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stepping Away from Sass

cathydutton.co.uk

Post reply on HN
Print view View original

71–80 of 157 posts

Re: Stepping Away from Sass

#71

Post by arvinsim »

everdev wrote: post #60
throwaway66666 wrote: post #55

Earlier quoted context omitted.

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 be…

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

Re: Stepping Away from Sass

#72

Post by steveax »

namelosw wrote: post #38
psychometry wrote: post #37

Earlier quoted context omitted.

There's no performance impact. Styles are precompiled locally before deployment.

There is, at runtime browser needs to do extra matching. https://stackoverflow.com/questions/13829959/nested-selector... It's about Less but the same rule applies to CSS and Sass.

Note the date on that. It’s my understanding that with modern browsers, except in pathological cases, selector performance is pretty much a non issue.

Re: Stepping Away from Sass

#73

Post by jaredklewis »

kbody wrote: post #51

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.

Yea, webpack sure is horrible.

Not like C/C++ programs, where we have a super simple setup of Make, config, and autoconf. Like checkout this easy-peasy Make file: https://github.com/apache/httpd/blob/trunk/Makefile.in . Even a child could understand it.

Or look at Java. Who has ever seen a complicated ant or pom file? No one ever. This Lucene ant file practically wrote itself: https://github.com/apache/lucene-solr/blob/master/lucene/bui...

/s

I guess my snarky point is that build systems are complicated. It's like the Bjarne Stroustrup about programming languages. There are two kinds of build systems: the ones people complain about the ones no body uses. Robust build systems have to handle the nearly endless combinations of different requirements each app brings to the table...complexity is table stakes.

Modern web apps are built to be able to run on a myriad of different platforms, as they have to maintain compatibility between tons of version of several different browsers running on a slew of different device types running different operating systems. Did we think that was going to be easy?

People like to shit on webpack, but I don't get it. It's a well thought out tool that works extremely well.

And what are the alternatives? Yes, yes, yes, I know, your blog/website/thing you have is just plain ol' html and and you stick some javascript in a script tag or whatever. No need for any of these fancy build scripts, blah, blah. So what? That's like telling the people at lucene that all this arcane index stuff is overkill because you just search your hard drive using ripgrep.

You can't make a real app like Slack, Spotify, VS Code, or Google Docs without a serious build process. People are making photoshop, for the browser. They're not going to do it with ES3 they write directly into a script tag.

Re: Stepping Away from Sass

#74

Post by denisw »

agge wrote: post #69
everdev wrote: post #60

Earlier quoted context omitted.

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 be…

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

Re: Stepping Away from Sass

#75

Post by dmitriid »

namelosw wrote: post #27
rhizome wrote: post #8

Earlier quoted context omitted.

Nesting is by far the biggest driver for me. I can do vanilla CSS in my sleep, but it's such a cognitive drag.

Nesting is bad, because moving any element would break your style. And there's also performance impact. I found scoped css like component or BEM just make sense, which only encourage you nest one level in block namespace.

BEM is just an awkward workaround for the lack of nesting.

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.

Re: Stepping Away from Sass

#76

Post by everdev »

arvinsim wrote: post #71
everdev wrote: post #60

Earlier quoted context omitted.

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 be…

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

Re: Stepping Away from Sass

#77

Post by frosted-flakes »

nkozyra wrote: post #58
frosted-flakes wrote: post #56

Earlier quoted context omitted.

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.

Your example is a bit confusing. This would be a more idiomatic way of writing it:

  .some-class {
      > div, a {
          background: blue;
          &:hover {
              background: red;
          }
      }
  }

Re: Stepping Away from Sass

#78

Post by smt88 »

BigJono wrote: post #68
djrobstep wrote: post #53

Earlier quoted context omitted.

"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…

Almost as annoying as being told the tech stack you've been using for decades is unreasonably difficult to use despite the almost literal millions of maintainable and successful projects deployed with it. If you want to talk about strangely pervasive attitudes in tech, surely point of call #1 is "I just learnt and can't possibly comprehend how people write software without it", no?

I've been writing CSS since the late 90s. SASS, especially nesting, makes it vastly easier to write, understand, and maintain. It's an unabashed win.

When kids tell say that CSS sucks, it's not annoying at all. Things change, people learn, and tools get better.

People questioning and improving old things is good, not annoying.

Re: Stepping Away from Sass

#79

Post by everdev »

intertextuality wrote: post #70
everdev wrote: post #60

Earlier quoted context omitted.

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 be…

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

Re: Stepping Away from Sass

#80

Post by thecatspaw »

marcus_holmes wrote: post #63
yawaramin wrote: post #43

Earlier quoted context omitted.

> I can assume that it's not injecting malicious code into my application. 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?

useful, I didn't know about this. Thanks. How does the reporting of vulnerabilities work for npm? 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.

isnt it very common to use github repositories as a library? I seem to recall that this was the way to get libraries, though it has been a few years since I looked into go
Post reply on HN