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

131–140 of 157 posts

Re: Stepping Away from Sass

#131

Post by h1d »

whoisjuan wrote: post #3

I honestly have never seen the value in pre-processors when writing CSS. I think they abstract a lot of low-level understanding of your UI and make your stylesheets overly complex. They definitely keep things sane when doing CSS at very large scale (for example dealing with color palettes, fonts, etc) but are not that useful when you're writing different components with different rendering needs. Nowadays I just do f…

So you still type all this,

  .selector .child_one,
  .selector .child_two {
     color: #000;
  }
instead of,

  .selector
    .child_one,
    .child_two
       color #000
I no longer type a semi colon when developing a web site thanks to preprocessor and transpilers.

Re: Stepping Away from Sass

#132

Post by wutwut5521 »

marcus_holmes wrote: post #103
marcus_holmes wrote: post #65

Earlier quoted context omitted.

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

just got this working with fswatch and sassc, thought I'd feed back that this is perfect, thanks :)

Heh, I just woke up and read this and thought “well thats enough problem solving for today” :) Glad we could help you avoid the hell that is adding npm to a non-node project!

Re: Stepping Away from Sass

#133

Post by wutwut5521 »

jayshua wrote: post #46
wutwut5521 wrote: post #42

Earlier quoted context omitted.

You might be thinking of libsass. sassc is dead simple and solves all of this users issues.

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

You have to compile it, just like this poster has to compile their go code. There are usually packages and formulas for it in most std repos.

Re: Stepping Away from Sass

#134

Post by topicseed »

kangoo1707 wrote: post #91
topicseed wrote: post #87

Worked a lot with CSS for 10+ years and SaaS' nesting is amazing. I still have no clue when to NOT nest, but oh well, it is so useful to componentize the stylesheets.

Nesting is okay for one-level. However it violates the principle of least astonishment. How come a button inside .header differs from the button inside a .footer, then where are the differences defined, inside the button.scss or header.scss? Then one must take into consideration CSS Specifility and sprinkle !important everywhere. Instead, use modifier (in BEM) or create two buttons (.header-button and .footer-button)…

Yep, makes a lot of sense. I usually follow these guidelines but with larger "code as you go" projects, it gets a tad dirty.

Chrome Dev Tools help to find what's glitchy when styling misbehaves.

Re: Stepping Away from Sass

#135

Post by jaredklewis »

type0 wrote: post #100
jaredklewis wrote: post #73

Earlier quoted context omitted.

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/bl…

> People like to shit on webpack, but I don't get it. It's a well thought out tool that works extremely well. The problem isn't that webpack is bad but too many projects use it where there's not need for it. Also for newcomers to the js world it looks terrifyingly complicated. Sure those bootcamp rookies eventually discover how terrible C++ buils are but who cares since this is more like comparing a spoon with a shov…

> The problem isn't that webpack is bad but too many projects use it where there's not need for it.

Well, I feel that bit of nuance gets lost most of the time. It’s usually just simplified to “all these JS tools are a mess.”

It’s like if people all started complaining that rust is bad because they saw someone write a rust program when that person should have just written a bash script.

Re: Stepping Away from Sass

#136

Post by _bxg1 »

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?

The problem is that "doing it the hard way" isn't just a matter of the original programmer having to put in "more effort". It's not just a matter of sucking it up. Needlessly esoteric code is less expressive, and therefore harder to maintain, and therefore will statistically have more bugs and have to be replaced sooner. That's the real cost. Masochistic programmers who insist on doing everything the hardest way possible, despite better available options, aren't taking the hard road for the sake of a better end product. They're making their end product objectively worse in the long run.

I didn't set out to attack CSS (I love CSS!), or even assembly for that matter. You're the one who's for some reason making this into a very weird hill to die on.

Re: Stepping Away from Sass

#137

Post by stephenr »

sureaboutthis wrote: post #115
stephenr wrote: post #36

Earlier quoted context omitted.

Use sassc and call it from your makefile.

So a tool to fix the tool that's supposed to make things better.

Huh?

SassC is just a cli tool that uses the C-language SASS library. It's an alternative to using whatever ridiculous NodeJS solution was/is being used.

Re: Stepping Away from Sass

#138

Post by stickfigure »

riz_ wrote: post #127
stickfigure wrote: post #124

Earlier quoted context omitted.

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

I see.

These solutions all seem quite a lot more complicated than nested scopes! And at least for styled components (angular, I presume) and styled-jsx (react), they're framework-specific. Why are these solutions better?

Re: Stepping Away from Sass

#140

Post by dfabulich »

stefanfisk wrote: post #89
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

when I use sass nesting it's almost always to do BEM style selectors via `&-`, which really is soo much easier to read than having to type the full selector every time, especially when you have A LOT of components in a directory structure. sadly this use case seems to be missing from the coming spec :(

https://github.com/w3c/csswg-drafts/issues/2701#issuecomment...

> Yeah, very intentionally not allowed. It causes parsing issues, for one (you can't arbitrarily split up an ident and be guaranteed that both halves are still idents), and it's grammatically ambiguous with tagname selectors.

There's an open issue https://github.com/w3c/csswg-drafts/issues/3748 "add note explaining that BEM `&__element` class accumulation isn't supported and why"

Post reply on HN