My “site” is spread across five different servers. I use slightly different CSS on each one. Since 2013 I’ve been using SASS to manage the variants, using these features:
- Variables → available in CSS since 2020
- Calculations → available in CSS since 2015
- Nesting → available in CSS since late 2023
Even though I want to use new browser features right away, I usually wait a year or two for them to stabilize and get into extended support releases.
A few years ago I had switched variables and calculations from SASS to CSS, but I still needed SASS for nesting. Since CSS nesting has now been supported for two years, I decided it should be safe for me to use it. And that means I no longer need SASS.
I divided the CSS into eight files that I can simply concatenate together (using…
My “site” is spread across five different servers. I use slightly different CSS on each one. Since 2013 I’ve been using SASS to manage the variants, using these features:
- Variables → available in CSS since 2020
- Calculations → available in CSS since 2015
- Nesting → available in CSS since late 2023
Even though I want to use new browser features right away, I usually wait a year or two for them to stabilize and get into extended support releases.
A few years ago I had switched variables and calculations from SASS to CSS, but I still needed SASS for nesting. Since CSS nesting has now been supported for two years, I decided it should be safe for me to use it. And that means I no longer need SASS.
I divided the CSS into eight files that I can simply concatenate together (using cat), then esbuild[1] to minify the result:
cat input1.css input2.css … \
| esbuild --loader=css --minify --bundle --external:* \
--outfile=output1.css
Since the web server uses gzip content encoding[2], does it really matter if I minify? Yes, it does, and the help from minify seems to be independent of the help from gzip:
Size reduction file when using gzip or minify
The main goal of this change was to reduce dependencies. But it looks like I still have a dependency on esbuild instead of on sassc. How is that better?
I have been maintaining my site for over 30 years. It’s older than Wikipedia or Google. Most software doesn’t last that long, and I don’t expect sassc or esbuild to last as long as my web site. When I’m choosing tools I ask myself “what happens when this software disappears?”
There’s a difference between the sassc risk and the esbuild risk. I’m using sassc to translate SASS to CSS. If it disappears (it’s already deprecated[3]), I have to manually translate it, or find an alternative. I can’t update the site without that software. I’m using esbuild only to minify. If it disappears, I lose an optimization but I don’t have to do more work. I can continue updating the site without it. So in terms of dependencies I’m happier with esbuild than sassc.
I generally want to prioritize changes that make the site better for readers. This change does not help in the short term. But years from now, when I want to fix a typo or add information to the site, it will be easier for me to update if I have fewer dependencies to update.