Rusty Cascading Style Sheets – Another CSS Preprocessor | Hacker News Reader

Rusty Cascading Style Sheets – Another CSS Preprocessor

github.com

23 pointsved_patel2269 comments

Vanilla CSS already has support for nesting and variables that are more flexible than this, cascade properly at runtime, and are available to alter with JavaScript at runtime. I don’t think it’s a good idea to reinvent that with a preprocessor.

Vanilla CSS doesn’t have mixins, but generally speaking those aren’t all that helpful anyway, there’s often a better way to achieve what you want using some combination of other HTML/CSS features.

I’m more inclined to write vanilla CSS and use Lightning CSS (also implemented in Rust) to transcode for backward compatibility with older browsers. Lightning also supports mixins via the compose property if you really want them, although that’s not standard CSS.

https://lightningcss.dev

this is the way. Modern CSS brings most of the capabilities to the table that SASS & LESS used to provide, and in part even much more functionality that could never be adequately solved with preprocessors (runtime calc(), light-dark() and layers come to mind)

I'm still a fan of LESS, but quite specifically because it _does not_ try to force another languages syntax into my preprocessed stylesheets, rather keeps everything as css-like as possible. This makes it much easier to transition things to vanilla-only when possible, absolutely dreading "mostly js"-types of SASS frameworks

I will use SCSS as long as vanilla CSS retains its idiotic comment syntax. I would replace html with pug for the same reason if the Svelte preprocessor didn’t break so much tooling and preserved source-maps.

But seriously.. multi-line comment syntax that blows up when it encounters a nested comment is infuriating and a slog in huge projects, particularly during multi-line editing.

The same reason why trailing commas should be mandatory by law and semis should be punishable by wedgie.

CSS Custom Properties have a cost. If you’re using them as global variables, and don’t need to look them up from JavaScript, or change them according to media queries, it’s good to flatten them out of existence: your bundle will be smaller, your execution faster, and your memory usage reduced. Same with mixins.

It would be good if Lightning CSS supported that use case: https://github.com/parcel-bundler/lightningcss/issues/69.

Compile-time variables are still a useful feature. CSS Custom Properties get used in a lot of places where compile-time variables would be better.

I'm glad that someone out there is working safety guarantees for CSS ;P

What are some safety guarantees for CSS?

It’s a joke…

Well it's got two S's-es so i want it to be double safe!

Hot take: CSS is actually type safe, just doesn't get compiled & fails gracefully ;P

Reply on news.ycombinator.com