Topic: “Front-end”

There has been a lot of bashing on pre-processors lately, and rightfully so. Sort of.

Certainly, these tools, such as SCSS and LESS, can result in excessive bloat and specificity issues in their generated CSS. Lyza Gardner struck the nail on the head in A List Apart this month:

Pre-processors have a way of keeping us at arm’s length from from the CSS we’re building. They put on us a cognitive burden to keep up on what’s evolving in CSS itself along with the tricks we can pull off specific to our pre-processor. Sure, if we’re intrepid, we can keep on top of what comes out the other end. But not everyone does this, and it shows.

But when it comes to pointing the finger, we should be looking at the author, not the tool he uses.

Pre-processors caught on largely because they made it easier to create scalable CSS that paralleled the structure of a pattern library. They made it easier to track variants off of a single element without duplicating any code or requiring additional class names on a single HTML element.

When used correctly, they make coding CSS – and more importantly, maintaining a large CSS code base – so much easier.

To truly take advantage of the strengths of pre-processers, we have to be aware of their limitations and weaknesses, plan accordingly, and think ahead. You could say the same thing about HTML, Javascript, image use, etc. Like any tool, a pre-processor is only as strong as the person who wields it.