Whether you’re building a collection of stateless webpages, a single-page application, something in between or beyond then you’re likely to face the decision at some point over how you manage large quantities of CSS so that it’s better optimised and efficient.
A few years ago it seemed like the industry was in one of two camps when it came to pre-processing CSS on a large scale: you’d choose Sass or Less. Today the rapid adoption of frameworks like React, Angular and Vue has changed that landscape with a growing crowd in the web industry keenly debating the case for CSS-in-JS.
Knowing the principles of how Vanilla CSS is written has an important place in the hiring process for any half-decent developer or design role working in the web industry. Vanilla CSS, or just CSS, as some of us remember it, has caught up ground in recent years with its abstracted relations such as Sass and Less. The more recent option to add variables directly into a CSS file is one of the first steps toward making Vanilla CSS more adherent to the DRY principle. This is of particular use for the duplicate use of things like colours and sizes over multiple properties inside the CSS.
The dynamic nature of single page applications means that we have to keep the visual styles of page components and the overall page container (or app shell) updated in sync with everything else. This helps prevent the user from seeing unstyled elements each time there is a change in state.
Sass (Syntactically Awesome Style Sheets)
Still one of the most popular methods to pre-process CSS, Sass, has developed into a feature-rich tool to manage everything including variables, mixins, operators and functions. With care related properties of a component can be nested within other selectors. This is so long as the nesting doesn’t go more that 2 or 3 levels deep which can result in complex and even more bloated CSS than necessary.
Less (Leaner Style Sheets)
Sitting somewhere closely behind Sass is Less which works and is written in much the same way but with slight variations in its syntax.
Comparing Sass / Less
Stylus is a stylesheet language taking influences from both Sass and Less such as having variables, mixins and functions. Unlike them it’s programmed using Node.js and JADE. The clarity of syntax in Stylus is debatably more loosely written. It comes without brackets or colons being necessary to split up properties, their values and selectors.
PostCSS can be adapted in many ways to validate, audit and lint CSS written in different forms. This includes anything from plain external stylesheets to component-based styles, such as that used for CSS in JS and even Sass or Less. It’s dependent on using module bundlers such as Webpack or custom built modules for frameworks like React.
A common use case for PostCSS is to maximise cross-browser compatibility for newer or cutting-edge CSS properties. It can then apply prefixes and other fallback supports if necessary. Based on web browser support statistics from the popular site, Can I Use, PostCSS looks for the required fallback support and prefixes to apply to your compiled CSS code.
Of course these are just a handful of methods and tooling options for writing you CSS in 2018. There are countless customisable, open-source options for processing CSS to fit the needs of your product or organisation out there. Choosing how you write and process your CSS is a fundamental requirement to ensuring the future scalability of your website or application. Whether you’re working as part of a team or standalone then it’s important to think about which tooling offers the most flexility and maintainability for your CSS.