CSS Preprocessor Issues - Can we handle them Wisely?

Despite the popularity of CSS pre-processors, it has been found that a majority of developers who are writing CSS are actually writing in a specific kind of language that transpiles into CSS. Hence, this has posed as a visible disadvantage of using a CSS pre-processor. Reading this post will make you familiar with some of the well-known pros of CSS pre-processor and we'll also find whether there are techniques of handling the same in a perfect way.

Sass serves as an authoring tool, a configuration manager, framework and a transform and build tool. Although Sass has been quite successful in offering good support for minification, output formatting, concatenation and source maps, it comes with a major drawback. An unintelligent use of Sass can easily result in unwanted CSS. It is important to note that Sass has a malevolence which tends to manifest each time its yielded without a deep understanding or proper attention. Hence it is essential to avoid the overzealous use of Sass' @extend feature. Moreover, immoderate nesting can also lead to overlong, abstruse and over specific selectors.

Since the use of CSS pre-processors won't expect you to deploy the .less or .styl files, you'll need to have an additional step in the development life-cycle wherein the .css stylesheet is being generated. This extra step can considerably slow down the development pace. Fortunately, we have an easy access to some stunning tools like CodeKit or Grunt which will auto-compile the Stylus files to CSS. While such tools come with logical defaults, it is essential to pay special attention to their effective configuration. For example, on choosing Grunt, don't forget to check its 'Getting Started' guide so as to gather helpful insights on installation and use of Grunt plugins.

It is essential to know that each CSS Preprocessor comes with a different syntax. Even though some of the preprocessor features might overlap, they are being implemented differently. Moreover, with different syntaxes associated with different pre-processors, it becomes quite tedious to switch from one project to another wherein you're supposed to have a different styling syntax. For instance, on finding that a Stylus syntax is compatible with a LESS file, you'll be required to write the styles twice-leading to increased project time.

Unlike the case of writing CSS in a low-level styling language, writing it using a pre-processor will generate a CSS which will not be as small as you think it to be while you're busy editing the CSS. Well, there are multiple reasons for this. Some of the most prominent ones are explained below:

Unlike the case of pre-processors which come with distinct syntaxes, the post-processors feed on the original CSS stylesheet. These post-processors act like polyfills, allowing you to write the to-spec CSS which would work for your web development project. There are chances that you might be using a post-processor adjacent to your pre-processor without actually being aware about it. The very renowned autoprefixer tool is indeed a post-processor which allows you to fetch the CSS and add all the vendor prefixes so as to make the website work in multiple browsers. In contrast to the functioning of the pre-processors, a majority of post-processors(especially the ones written using a plugin approach) play a vital role in auto-generating the inline image data. That means, you are free to choose any of the modular plugins that are required for transforming your CSS.

That's it for now!

A thoughtful understanding of pros associated with CSS pre-processors is something that will aid you in creating excellent things for the internet. Here's hoping my post would have helped you in learning quite a lot on this topic.