At the Vue.js developer summit, we discussed this topic and did not reach a conclusion (see T286951). We need to revisit the pros and cons and decide on a path forward.
| Option | Pros | Cons | Notes |
| Less | Used in MediaWiki core, widely used at WMF. Would offer consistency with core and many extensions/skins. | Much less widely than Sass used outside of MediaWiki/WMF | Less was historically chosen by WMF because of its superior PHP implementation. Similar syntax and features as Sass. |
| Sass | Much more widely used globally than Less (meaning easier onboarding for new designers/devs), used in WMDE projects, useful features like `@extend` and logical programming support (see [[ https://phabricator.wikimedia.org/T289804#7323622 | Santhosh's comment ]]) | Would require core developers/WMF to use two slightly different pre-processors (potential for errors/higher cognitive overhead) | Similar syntax and features as Less |
| Native CSS (with PostCSS) | Close to future CSS standards. Removes the need for a pre-processor (which may be more future-proof), PostCSS is extremely customizable and much faster than Sass and Less. [[ https://github.com/postcss/autoprefixer | AutoPrefixer ]] support | Paradigm shift for developers who are used to pre-processors, lots of PostCSS configuration and plugins needed, some CSS features might not be comparable to pre-processor features (e.g.`@apply` doesn't accept arguments like mixins do), risk that specs for new, unstable CSS features will change | PostCSS will likely be used with any of these options for things like autoprefixing, but that it would be an absolute requirement with native CSS to transform new CSS features for browsers that don't yet support them |