The state of CSS and preprocessors
After all these years the sheer speed of change in web development never ceases to amaze me. This time the thing that got me by suprise was the state of CSS and especially CSS preprocessors.
For at least the entire 2015 the usage of preprocessors, especially Sass/SCSS, was on steady raise. Whenever I stumbled on an article or a blog post that had to do with CSS the code snipplets seemed to always be written in SCSS. Posts about tooling kept repeating a familiar chant: if you aren’t using a preprocessor yet, the time is now.
I begun using SCSS because of the great asset pipelines Jekyll and Rails provided. Building the CSS files was made so easy that there was no reason not to take the leap. The variables came in handy and nesting rules helped with organizing things (when used with moderation). Partials gave the styles a nice structure and even for
loops had their uses.
Recently the hype has been fading - or rather turning towards something else: enter native CSS variables. While the browser support for the feature is still notably low (IE/Edge has no implementation whatsoever at the time of writing) the hype is catching on. The general consensus seems to be that the need for preprocessors will eventually vanish entirely.
Native variables are obviously a more capable solution than preprocessor variables. Native variables can be modified on runtime with Javascript which opens a range of new possibilities (or a least makes some existing tasks much easier). Changing an entire site’s color scheme on runtime for example is just a matter of updating one native variable per color. Previously each element with a color would have to be altered (though the work could be somewhat reduced with some use of inheritance).
What about other main features of preprocessors? The most familiar feature for many is nesting. Not everyone thinks it’s such a good feature - it is dangerously easy to generate too specific selectors with overuse of nesting. Shallow nesting on the other hand can lead to better readability without a making rules any more specific.
SCSS nesting done right.
Looping comes in handy sometimes but it’ss easy to say that one could live without it. The syntax (in SCSS) is quite clean and provides good readability. Loop structures allow easy changes to structures like grids.
This is more or less what I replaced the Bootstrap grid with on my site.
The need for Sass style mixins is not so dire any more. Vendor prefixes on properties are becoming scarce and new features like the flexbox mean that the best practices for many layouts no longer consist of multiple rules. Outside the two use cases mantioned, you are propably better off without mixins. If it isn’t obvious to deduce the rules used by the name of the mixin, the mixin just reduces the readability. Mixins are not subroutines. (Related to this, there’s also inheritance, which I find a bit gimmicky in the context of stylesheets.)
Sass and its alternatives also provide a set of useful mathematical operations for calculating for example font scales or a percentage value of a width. As with variables native CSS once again provides an alternative: the calc()
function. The native function has quite a nice browser support and provides a good variety of useful features like the ability to mix units (percentage, em, px, vh) in math operations.
So is it still worth learning CSS preprocessors at this point? Despite the advancements in native features my answer is still a strong yes. For the time being I believe in a mutual existance between new native features and shortcuts offered by preprocessors. It’s obvious that the preprocessors won’t be the answer forever but in the meantime there is still much to do about CSS before it is the best tool it can be on its own.