Build outputs

July 09, 2016


Don’t get too lazy. Don’t be the, “Yeah, it works” developer. Be the developer that pays attention. Considers initial payloads. Optimises to get the best performance out of your code.

There’s a problem in the development community.

We’ve been accustomed to using tools like PostCSS, SASS, LESS etc that we use them when there is no need. On larger projects sure these are useful but on smaller projects - probably not.

What I’ve also seen on numerous occasions is that generated output of the CSS is often bigger, bloated and sometimes unnecessarily big. Common things like duplicated CSS, entries for zoom: 1, insane amount of vendor prefixes are all some of the culprits. Sometimes the difference between a @mixin versus a %placeholder in SASS could make all the difference.

There’s two problems here in my opinion:

  1. Not checking the generated source file
  2. Not understanding the full use of tools and its functions

Not checking the source is easy to do especially when there’s many things to do on a project.

The developer has to make sure that tool they’re using is being used efficiently and not as a means to an end. Don’t just use SASS, LESSCSS or whatever because its there to use. If you do though, check your generated output regularly to make sure you’re not introducing bloat. This could often introduce problems with specificity for example which could be harder to debug later.

Often tools will have options to enable/disable features which could prevent such problems but it is up to the developer writing the CSS to check this. Authors of tools could also be helpful here by exposing such information in the documentation - which at times is frustrating to find.

Next time you’re using some mixin or a SASS function then check your generated output. You’ll be more confident in your understanding of the tool as well as being sure that you’re writing optimal code ready to face the world.

Profile picture

Written by Qasim Alyas