It's great that parts of SCSS are getting superseded by CSS.

Nesting is great to avoid selector repetition.

Custom properties (CSS variables) and CSS functions give us tools to avoid magic numbers and to encode layout relationships.

New sets of selectors and container queries let us decouple and re-use declarations more.

CSS Houdini gives us further power in extending CSS functionality.

Of course there are things that SCSS provides which are unlikely in the scope of future CSS proposals such as datastructures (maps) and loops to generate classes and mixins. But I can already imagine a world were those aren't necessary anymore for many cases.

> SCSS are getting superseded by CSS.

Reminds me of how Coffeescript died out because its best ideas got integrated into Javascript.

What I want to know is: how the hell did this take so long? Nesting is such an obviously useful feature to have in CSS, and once I'd experienced it in SASS I never wanted to be without it. Why did it take 10+ years for this to be introduced to CSS, especially when other browser-based technologies like JS have evolved enormously in that time?

Some of the Less/Sass maintainers are also active parts of the communities that write the specs and I guess when the idea of nesting was fresh to these preprocessors they didn't feel compelled to make it a core part of css with how widely the preprocessors were getting adopted. While I don't doubt our computers 10+ years ago could parse through nested styles it's probably really trivial now and thus being implemented into core.

As far as the speed of which things get implemented, I often feel there is a lack of understanding where design and development overlaps. Most devs are just devs in the sense they solve algorithmic/browser rendering problems, and don't really dabble enough with markup/styling languages like HTML and CSS to hit the pain points of using them. And the people that deal with markup/styling do not know the proper channels to rally behind some of the ideas that would make their lives easier. Unfortunately, there are less individuals that are proficient at markup, styling, and programming (not just in the sense of coding in JS/TS, but understanding the internals of the browser and programming for it), and the unicorns that do understand are often snatched up by Google/Microsoft/etc. which often have their own agendas. I feel there's just a lot more niche backdrop knowledge that is required to get the ball rolling. These are just my feelings on this matter, I could be wrong.

For another take: I try to write a single module.css file per component in which I do zero nesting, avoiding any preprocessors (other than postcss modules, obviously). Nesting, IMHO, makes CSS a bit easier to write but much harder to read.

For me this is where something like PostCSS shines. You simply write future css and remove the plugin when it’s supported natively.

This wins in my opinion because there shouldn’t be any conversion necessary from something like Sass to CSS

What's the hit/miss rate on that CSS changing syntax?

I Vaguely recall something similar happening with decorator syntax/how it worked in JS/typescript.

Or do you keep to CSS features that are locked down in terms of spec, just waiting on implementation to roll out?

That decorator syntax thing was a mess. The original syntax seemed like it was far enough along. Many folks adopted it because it seemed like "a sure thing". I ended up pulling it from a project in 2017 because so few of the folks on my team wanted to truly understand what problem those were meant to solve. It was easier to "decorate" in a more manual way (wrapping a function with a function).

The way TC39 handles stages now should stop things like that from happening. (You implement a Stage 1 or 2 feature fully knowing it could change)

It’s your call fortunately/unfortunately.

The safe option is obviously to install plugins for features that are close to passing as possible, where the api is stable at least - but there are plugins for very early stage proposals too.