Stepping Away from Sass • Hacker News Board

Re: Stepping Away from Sass

#61

Post by jaabe » Fri, Apr 26, 2019, 4:53 AM UTC

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.

Well some of us think webpack/react and the rest are even worse and that a page-reload never killed anyone.

I don’t work in a tech-focused business, because I work in the public sector. That means our funding is fairly limited, even though 90% of our workforce spends 5-8 hours a day on some for of smart device or pc. Because we’re limited, however, we need to be careful about how we spend our resources, and that means we simply can’t keep up with the modern frontend environment.

If all you do is angular, then the transition from AngularJS to angular 2 might have been smooth, but it sure wasn’t for us, and neither would the big react-versions be.

We also can’t really take advantage of the package/library environment because we’re not as fault tolerant as others. We can’t have security issues, but we also can’t code-review 70 packages/libraries every week because there was an update.

As a result we’re back to using the old MVC frameworks that don’t change every day and have solid standard libraries. We did buy a frontend “platform” so we can have things like editable grids without constant page-reloads, but in general, JS is something we add to a specific component only if it’s absolutely necessary.

I am looking forward to when Flutter finally has the ability to build websites. Because then we’ll have both mobile platforms, web and desktop frontends covered in one tool. Which is frankly exactly what we need to be productive in 2019, that or we’d need to hire 2-3 people, and the latter is just not happening.

Re: Stepping Away from Sass

#62

Post by pcurve » Fri, Apr 26, 2019, 5:00 AM UTC

Waterluvian wrote: post #9

I read somewhere a quote like, "a bad abstraction is worse than none at all." And for that I'm always on the lookout for things that look the same but aren't actually. Careful not to merge them via abstraction because they might deviate heavily all of a sudden and now you have to refactor a lot. CSS is the #1 place where I spot those cases. And I feel that Sass and other CSS preprocessors mostly lend themselves to sh…

Duplication is better than wrong abstraction... is probably what you meant to say

Re: Stepping Away from Sass

#63

Post by marcus_holmes » Fri, Apr 26, 2019, 5:18 AM UTC

yawaramin wrote: post #43

marcus_holmes wrote: post #29

Earlier quoted context omitted.

>>Does a preprocessor really complicate the workflow? 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, whic…

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

Re: Stepping Away from Sass

#64

Post by lyjackal » Fri, Apr 26, 2019, 5:21 AM UTC

_bxg1 wrote: post #52

BigJono wrote: post #50

Earlier quoted context omitted.

Sorry, I'll elaborate. These kind of sweeping statements are usually pretty obviously false. You can write anything cleanly at scale. Those MS-DOS sources that were released a while back are pleasant enough to read despite being in assembly.

The implied meaning of "impossible" in this kind of context is "unreasonably difficult". Just as it would be unreasonably difficult to write modern Windows in assembly, it would be unreasonably difficult to maintain a large CSS codebase without nested selectors.

You make a good point. CSS to SCSS doesn't seem like that big of a step up though. I don't really think nesting is really the greatest solution to the problem. It's got priority caveats over BEM, and can cause messes of it's own when used without precision.

Re: Stepping Away from Sass

#65

Post by marcus_holmes » Fri, Apr 26, 2019, 5:25 AM UTC

tangue wrote: post #57

jayshua wrote: post #46

Earlier quoted context omitted.

Correct me if I'm wrong, but doesn't sassc require the user to compile it?

You're right, on OSX you can brew install sassc

there's a Debian package :) thanks for the tip :)

Re: Stepping Away from Sass

#66

Post by actionowl » Fri, Apr 26, 2019, 5:25 AM UTC

I need more coffee, I misread "Sass" as "SaaS" until several sentences in...

> I also unintentionally, (at least at first) removed all traces of Sass from my codebase.

Especially this part, still thinking that was "SaaS" :)

Re: Stepping Away from Sass

#67

Post by luckylion » Fri, Apr 26, 2019, 5:30 AM UTC

What I really love about sass is using https://include-media.com/

I hate writing media queries, but

  @include media("tablet") {
  }

Takes most of the pain away.

Re: Stepping Away from Sass

#68

Post by BigJono » Fri, Apr 26, 2019, 5:31 AM UTC

djrobstep wrote: post #53

BigJono wrote: post #44

Earlier quoted context omitted.

> The only thing I still couldn't live without is nested selectors. Writing maintainable CSS at scale is impossible without them. Bullshit.

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

Re: Stepping Away from Sass

#69

Post by agge » Fri, Apr 26, 2019, 5:42 AM UTC

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…

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.

Re: Stepping Away from Sass

#70

Post by intertextuality » Fri, Apr 26, 2019, 5:56 AM UTC

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…

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.