[JoshTriplett]

Among many other reasons people have given (including eliminating the need for preprocessors): building this into the browser also allows for optimization, compared to expanding into a huge amount of CSS. If people can send one mixin and twenty invocations of it, rather than 20x the amount of CSS, then that doesn't just save bytes, it potentially allows the browser to directly generate its internal data structures and whatever caches/etc it needs, rather than parsing more textual CSS.

[wrs]

This will eliminate the need for CSS preprocessors about as much as each annual edition of JavaScript eliminates the need for JS preprocessors.

[SahAssar]

There is only one major JS feature that is missing from modern browsers IMO: type annotations (like https://github.com/tc39/proposal-type-annotations/ or similar) since most people don't want to use JSDoc-based ones. Some people will want JSX too.

After those the major use-case for JS preprocessors will for most use-cases only be bundling and minification.

[wrs]

Good to know we have completely run out of ideas and TC39 can disband as soon as they get through with that proposal! /s

[SahAssar]

New features will come, but my point is that the major non-standard features most people use that is not implemented in most browsers are better support for types and JSX.

Just look at the history of 6to5, babel, pony/polyfills, different build systems, different module systems, multiple different syntaxes like coffeescript, multiple different type systems. IMO we are much closer to the browser now and hopefully close to getting "normal developers" to write code that runs verbatim in a "normal browser". The outliers will always be there (Svelte, elm, etc.) but for mainstream code I hope to get back to shipping the code you wrote.

I hope that we get more features from TC39 after that. I think generators and asyncIterators are underused currently. Things like pattern matching sounds interesting to get into the JS ecosystem.

[jszymborski]

I no longer need a framework or build systems for my websites because all the features I used in jQuery are part of Javascript today.

I wouldn't need Sass if mixins were implemented in CSS.

It might not eliminate it for everyone, but it will for those who care.

[mattrick]

If this feature were added, I’d see very little need to use CSS preprocessors - at least for me. We already have variables, nesting, and color functions. Throw in mixins and user defined functions and that pretty much covers 90% of what I’d usually do in Sass.

Maybe you still use PostCSS for some auto prefixing/ backwards compat stuff but the need for that should go away as the usage numbers for unsupported browsers go down.

[tacone]

The preprocessors are here to stay though. They have been instrumental to build consensus about which new features are the right ones to incorporate. For what it concerns the JS/CSS/HTML the (good) outcomes are hard to deny.

[mminer237]

I feel like eliminating the compilation step adds more client-side processing. Instead of knowing this element gets this rule with this color, it has to do so many function calls just to find out what elements a rule styles, then it has to do all the math to compute all the colors needed just to get to where they're starting right now. Instead of the publisher doing the compilation once as part of its build step, this offloads that compilation to every single visitor.