What is PostCSS and how it differs from Sass

WHAT THIS TESTS This probes whether you understand the architectural difference between a fixed-language pre-processor and a plugin-based transformation tool, and how they fit together in a real pipeline. Many candidates wrongly equate PostCSS with Sass.

A GOOD ANSWER COVERS PostCSS is a tool that parses CSS into an abstract syntax tree and lets plugins walk and transform that tree, then serializes it back to CSS. By itself it does almost nothing; its power comes entirely from the plugins you enable. Popular plugins include autoprefixer for vendor prefixes, cssnano for minification, postcss-preset-env to use future CSS syntax today, and various linters. This makes PostCSS a platform, not a language. Sass, by contrast, is a pre-processor with a fixed, opinionated feature set, variables, nesting, mixins, that you author in and compile to CSS. They are not competitors but complementary stages. A common pipeline authors in Sass, compiles Sass to plain CSS, then pipes that CSS through PostCSS for autoprefixing, minification, and polyfilling. The mental model is: Sass for authoring conveniences, PostCSS for post-processing and standards transforms.

COMMON WRONG ANSWERS Calling PostCSS just another pre-processor like Sass. Assuming you must choose one or the other. Thinking PostCSS has built-in features rather than relying on plugins. Believing PostCSS replaces autoprefixer rather than running it as a plugin.

LIKELY FOLLOW-UPS Why is the plugin model significant? What order do Sass and PostCSS run in? Which common plugins would you enable? Could PostCSS plugins replace some Sass features, like nesting?

ONE CONCRETE EXAMPLE A build authors components in SCSS using variables and mixins, compiles them to a single CSS file, then runs that file through PostCSS with autoprefixer to add vendor prefixes based on a browserslist target and cssnano to minify for production. Sass handles the ergonomic authoring; PostCSS handles the compatibility and optimization steps afterward.