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

21–30 of 157 posts

Re: Stepping Away from Sass

#21

Post by gitgud »

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…

Well said, creating good abstractions is hard and takes careful consideration. Hopefully the abstraction has some kind of benefit; simplicity, flexibility or extensibility. I've personally found SASS to be cumbersome with the encouraged nested of CSS and tightly couples the CSS to the DOM markup.

A better abstraction in my opinion is a utility CSS library like Tailwind.css. It feels strange at first, but compose-able utility styles eventually feels like a good abstraction, with less shots to your feet.

Re: Stepping Away from Sass

#22

Post by gitgud »

rhizome wrote: post #8
statictype wrote: post #2

Does a preprocessor really complicate the workflow? Variables are still new and not fully supported. Being able to nest css selectors is major win for me. Reusable mixins is another. I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.

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

I feel that yes SASS requires less source code, but the nesting is kind of an anti-pattern and encourages complex hierarchies of styles which are hard to follow and maintain.

Re: Stepping Away from Sass

#24

Post by lugg »

nine_k wrote: post #16
wwweston wrote: post #4

Earlier quoted context omitted.

I still use less & sass on most projects, but it's occurred to me that: * Duplicating the effect of mixins by just... having another css class for the mixed-in stuff works well enough for many cases (though this hurts most where you're trying for semantic selector naming conventions, with mixins adding in rulesets behind the scenes). * Nesting selectors save thinking and some typing regarding where styles cascade out…

Writing pure CSS and copy-pasting things here and there is easy when you start. Where SASS shines is when you need to do a coordinated change, e.g. these things become gray instead of black. You have a ton of black things so no search and replace. And once you've painstakingly determined and edited the classes, the hard part is to be sure that you only changed what you had to, and nothing unrelated. SASS preserves se…

You mean variables?

Because I've seen sass refactors go just as badly.

Re: Stepping Away from Sass

#25

Post by baddox »

statictype wrote: post #2

Does a preprocessor really complicate the workflow? Variables are still new and not fully supported. Being able to nest css selectors is major win for me. Reusable mixins is another. I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.

Don't forget that SASS lets you use sane single-line comments prefixed by a double-slash. Heck, I'd use it just to avoid the laughably terrible /* CSS comment syntax */.

Re: Stepping Away from Sass

#26

Post by hombre_fatal »

ethhics wrote: post #6

Hi, undergrad here. That is to say, I’m not anything close to an expert in web design, but just in the course of making a simple static website to show recruiters I realized a lot of lessons like these about how modern HTML/CSS/JS can really handle anything you throw at it without having to worry about frameworks or precompilers. Sure, Bootstrap and SASS helped get a prototype up fast, but I feel like that gain in pr…

At the same time, you have to ask yourself if your customizations are so important that it's worth maintaining your own CSS. There are obvious trade-offs there. CSS files often incur irreversible complexity without someone dedicated to fight it. Forgoing a CSS framework completely has its own large costs like eternal vigilance, organization, and documenting some sort of strategy for other developers to follow (since they can't just read a framework's docs anymore).

Re: Stepping Away from Sass

#27

Post by namelosw »

rhizome wrote: post #8
statictype wrote: post #2

Does a preprocessor really complicate the workflow? Variables are still new and not fully supported. Being able to nest css selectors is major win for me. Reusable mixins is another. I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.

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.

Re: Stepping Away from Sass

#28

Post by jorgesborges »

rhizome wrote: post #8
statictype wrote: post #2

Does a preprocessor really complicate the workflow? Variables are still new and not fully supported. Being able to nest css selectors is major win for me. Reusable mixins is another. I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.

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 only an asset with thoughtful consistency. There are so many different ways to organize a stylesheet with nesting it can easily become unruly. But I like it now because I've found a method that works for me while also cleaning up my html.

In some cases I can preclude the necessity of having to declare class names.

section {

  h1 {},

  p {},

  img {},
}

In other cases I have an index with easy-to-find classes.

.hero {

  .gradient {},

  .description {},

  .signup {},
}

EDIT: I meant to reply to a different comment but oh well.

Re: Stepping Away from Sass

#29

Post by marcus_holmes »

statictype wrote: post #2

Does a preprocessor really complicate the workflow? Variables are still new and not fully supported. Being able to nest css selectors is major win for me. Reusable mixins is another. I just don’t see a compelling enough use case today to switch to pure css for non trivial applications.

>>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, which compiles the scss to css. But that requires node.js, and npm (there are golang scss compilers, but all of them are either not being maintained, or have problems, or only support older versions of scss). I have to run this in a separate terminal so I can stop it when I need to.

I've deliberately not looked at my global node_modules directory. If I don't look, I don't have to worry about how many js libraries just got installed on my machine, and I don't have to think about who's maintaining them, and if they're now malicious. As long as sass only touches the css files, and css isn't Turing-complete (yet), then I don't need to audit any of that, and I can assume that it's not injecting malicious code into my application.

Though there are possible attacks on my site that could originate with code injection from a $malicious_left_pad js library, even via css, but it's enough of a stretch that my paranoia can live with it. I can check out the compressed css every now and again and see that it's not importing anything it shouldn't, and be reasonably sure that I haven't just compromised all my users' security.

So yeah, it's not so much that a preprocessor is a complication, it's that a preprocessor allows a malicious package to compile whatever it likes into files that I will then serve from my domain to my users, who trust that I'm not serving them malicious files. That's policed not at all by npm, or any of the package managers, who cheerfully assume that all javascript developers are honest.

Re: Stepping Away from Sass

#30

Post by btmiller »

ethhics wrote: post #6

Hi, undergrad here. That is to say, I’m not anything close to an expert in web design, but just in the course of making a simple static website to show recruiters I realized a lot of lessons like these about how modern HTML/CSS/JS can really handle anything you throw at it without having to worry about frameworks or precompilers. Sure, Bootstrap and SASS helped get a prototype up fast, but I feel like that gain in pr…

It’s going to depend. If you’re going into the web front end field, you’ll be able to make that determination yourself.

For me, as an SRE with higher priorities, you can pry Bootstrap from my cold, lifeless fingers :) I have zero interest in keeping up with latest and greatest in CSS developments; like you said, Bootstrap gets you something up and running fast without much fuss. It’s good enough and it allows me to focus on other important areas.

Post reply on HN