Goodbye Sass
40 points by carlana
40 points by carlana
Most software doesn’t last that long, and I don’t expect sassc or esbuild to last as long as my web site
And that's the reason I forked[0] https://github.com/dchest/cssmin 12 years ago and have been using the same binary to minify my CSS without any problem or dependencies.
[0]: forked as in Github fork, I never changed a single line, just mirrored it
You’re missing out on a lot of awesome new css features
Please elaborate how minifying existing CSS can unlock new features.
Oh, I just assumed your fork chokes on new css primitives? Perhaps that was a bad assumption?
cssmin is a bunch of regular expressions. (Look at the code, it’s short.) It’ll miss lots of optimisation opportunities, it’ll break some things here and there, but overall it’ll tend to get within cooee of a proper AST-based compressor, without needing features like nesting to be added to its model before they’ll work.
I just used a Hugo theme that required sass and then I had to install 200MB of Dart. That seemed a bit excessive.
I just used a Hugo theme that required sass and then I had to install 200MB of Dart. That seemed a bit excessive.
Am unclear as to why that would be necessary, given the documented procedure. Of course, your use may be a special situation.
In my own Hugo project, although I don’t currently use Sass, I do keep it around in case I change my mind; and the latest version’s download is only 9.7 MB on disk.
I think homebrew pulled it in automatically. I was just trying out a lot of Hugo themes some of which have more involved requirements than others.
sassc is deprecated because the active maintenance of Sass is happening on dart-sass now, not because Sass is disappearing. Love the sentiment of reducing external dependencies anyway!
I've also stopped using CSS preprocessors, but I did notice that in practice calc() and var() do not always work as expected (yet?) in @media and/or @container queries. There's also still issues with calculations involving multiple different units. Not worth the extra dependency for me, but still.
I recently started using Sass (note the casing) again after going without a preprocessor for a few years. I just like the indented syntasyntax, the occassional loop/function you can’t do vanilla, & they finally fixed the bug where you couldn’t break a property over multilple lines in Sass syntax. I used SugarSS for a few years, but found the PostCSS pipeline too brittle with updates—& with Sass moving from Ruby years ago, it’s compiled fash enough to not notice it.
It's cool they added nesting to css, but unfortunately they didn't do it in a way that help with BEM approach which is something I quite like to establish proper namespacing. You can't do the following in vanilla css
.foo {
// match .foo__bar
&__bar {
....
}
}
That said, for the simple sites like that one it's not as motivating
CSS nesting in combination with custom elements/attributes has almost eliminated my need for BEM or other naming conventions as you only have to name the root element:
<custom-element active="true"></custom-element>
custom-element {
&[active="true"] {
background: red;
}
}
Consider making active a boolean attribute, like <details open>. (That is, the attribute’s presence defines it, and the actual value doesn’t matter and should normally be an empty string.) <custom-element active>, &[active], &c.
Fwiw, my company disallowed &__bar because you can’t grep for foo__bar and find all references if you name it like that.
A good dependency has to live longer than its consumers. Or at least, longer than its consumers want it. Anything stacked between the underlying platform and the application represents some rework risk. It's a great outcome when the platform copies and obviates a popular dependency.