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

121–130 of 157 posts

Re: Stepping Away from Sass

#121

Post by gitgud »

type0 wrote: post #99
gitgud wrote: post #21

Earlier quoted context omitted.

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

> A better abstraction in my opinion is a utility CSS library like Tailwind.css Exchanging sass with postcss based framework in my book is the worse abstraction for almost any purpose.

Why is that? Have you used it for significant projects? I've found the hierarchy of CSS classes and where they're defined (e.g. global or component) become hard to to manage and refactor when you want to reshuffle components around...

I feel postcss-based styling is simply more predictable and easier to refactor. And the abstraction, which can be clunky at first, becomes a sort of intuitive DSL which let's you develop faster...

Re: Stepping Away from Sass

#122

Post by gitgud »

rhizome wrote: post #32
gitgud wrote: post #22

Earlier quoted context omitted.

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.

How come I haven't experienced these downsides?

Probably for the same reason some people don't see the downsides of C++ or Java... you tend not to see the downsides, if you're good at it.

I just feel that nesting (which Sass encourages) leads to complexity and fragility.

Re: Stepping Away from Sass

#123

Post by HelloNurse »

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…

> This attitude is strangely pervasive on Hacker News, and it's very annoying.

Hard and annoying.

Re: Stepping Away from Sass

#124

Post by stickfigure »

gitgud wrote: post #22
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.

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.

Hi, you seem to be the leading critic of nesting on this page, so I have a question for you.

Assuming you're using a component framework like React, Vue, or Angular (and not a shadow dom based system like Polymer), how do you isolate your component CSS?

When I make a component 'MyComponent', I give it the className 'MyComponent'. Then I can create a SCSS file and scope its entire contents:

    .MyComponent {
        // all the css specific to MyComponent
    }
Without nesting, how do you keep your component-specific CSS from polluting the rest of your app? Do you scope every rule every time? Isn't that tedious?

Re: Stepping Away from Sass

#125

Post by gitgud »

stickfigure wrote: post #124
gitgud wrote: post #22

Earlier quoted context omitted.

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.

Hi, you seem to be the leading critic of nesting on this page, so I have a question for you. Assuming you're using a component framework like React, Vue, or Angular (and not a shadow dom based system like Polymer), how do you isolate your component CSS? When I make a component 'MyComponent', I give it the className 'MyComponent'. Then I can create a SCSS file and scope its entire contents: .MyComponent { // all the c…

Thank you, I'll wear the title of: leading critic of nesting proudly! disclaimer I'm not a hugely experienced programmer, but have done a few open source projects in Vue, React and am currently working on a series of Angular applications with a team at work.

In Vue and Angular component styles are automatically encapsulated at the component level by scoping (I think) so nesting isn't really necessary to target specific components. Angular also recently deprecated a method of breaking out of component styling and soon it will be completely removed from the framework.

Although I'm a critic I'm not totally against nesting, I just feel that SASS encourages it, so without discipline things can get very complex and fragile. One level of nesting is OK with me though I suppose...

Re: Stepping Away from Sass

#126

Post by Raphmedia »

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.

When we are talking about nesting we are not talking about generating `.page #left-section .box .button {}`... This would be bad. Nesting used properly is something like `.myWidget .button, .myWidget .title, .myWidget .main-section {}`. You can then move .myWidget anywhere you want and the styles would follow.

Re: Stepping Away from Sass

#127

Post by riz_ »

stickfigure wrote: post #124
gitgud wrote: post #22

Earlier quoted context omitted.

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.

Hi, you seem to be the leading critic of nesting on this page, so I have a question for you. Assuming you're using a component framework like React, Vue, or Angular (and not a shadow dom based system like Polymer), how do you isolate your component CSS? When I make a component 'MyComponent', I give it the className 'MyComponent'. Then I can create a SCSS file and scope its entire contents: .MyComponent { // all the c…

Not OP, but you could use CSS modules, styled components or styled-jsx, all of which auto-generate unique classnames (styled-jsx uses a HTML attribute for it, I think).

Re: Stepping Away from Sass

#128

Post by ethhics »

mjlangiii wrote: post #13
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 is a bit of catch-22 IMHO, for some. If you're very experienced it is just as easy to roll your own (although others may not onboard as quickly compared to well known libraries). If you're not very experienced then if you try to roll your own it may wind up being a mess. I'm in the middle and once I understand a library well I know its limitations and use its components as they were intended where I won't have to…

Certainly! I wanted to hear some viewpoints about full vanilla vs framework-based development, and your view of grokking the tools and implementing what it doesn’t cover is a great one to consider.

Re: Stepping Away from Sass

#129

Post by Theodores »

bbx wrote: post #107

The case for CSS variables is interesting. I'm still trying to figure out the best way to integrate them with a CSS framework I created, called Bulma: https://bulma.io/ There's a few ways to combine Sass variables and CSS variables: - make all Sass variables available as CSS variables as well, so $primary will also exist as --primary - assign a CSS variable to a Sass one: $primary: var(--red) - assign a Sass variable…

> why offload the variable resolution to the client side when it can be done at compilation time?

Imagine I have a property that I need to change depending on screen resolution in order to make a responsive layout.

In my CSS rule I specify it to have a fallback default and to take a CSS variable that over-rides it.

Elsewhere in my CSS I define the CSS variable with a media query.

The CSS rule is quite clear in that it shows that something changes or can change.

In the olden days I would be declaring the CSS rule twice. Once for the default and once inside the media query.

With the old fashioned approach it would not be clear looking at the CSS rule that it had an over-ride somewhere else in a media query.

By using the CSS variable with a fallback in just the one rule I know that something in the rule changes. I can easily find the CSS variable, regardless of how it has been scoped to see what makes it get set. Since I know the convention for most of the CSS in the stylesheet, e.g. mobile first, I can guess that the variable is for the desktop setting.

The advantage is that I have code that I can hand on to the next guy and feel happy that even if they are not yet up to speed on CSS variables they will be able to easily work out what is going on with individual rules.

There is no point in Sass variables now, they are defunct. All of the functionality is superseded and there is no point learning two ways to achieve the same task when you can just master one. This trumps any 'compilation' speed ups, resolving variables is something that does not slow page load times.

The only use case for not using CSS variables is if you have to support people using extremely old browser.

Re: Stepping Away from Sass

#130

Post by h1d »

dfabulich wrote: post #84

A lot of folks here are saying that they couldn't live without nesting CSS selectors. FYI the CSS Working Group approved a working draft of native CSS Nesting last month; it's in "stage 1." https://drafts.csswg.org/css-nesting-1/ There's a PostCSS polyfill you can use for it today. https://github.com/jonathantneal/postcss-nesting

Preprocessors like Stylus has all you want and in a better way (ex : variable declaration).

I already have something better than CSS in 5 years when most browsers in the market get the newer CSS, so I don't see a point in following CSS now.

Better to spend time making the preprocessor more accessible to developers.

Post reply on HN