The Magic Before CSS - Preprocessors

Introduction

In the field of front-end development, some commonly heard preprocessors, such as Sass, Less, and Stylus, what are they? Why do they exist? This article will mainly explore the following key points (with examples):

  • What is a CSS processor?
  • What benefits does it provide, and why do we need them?
  • What preprocessors are available to choose from?
  • Reasons why you might not want to use a preprocessor

What is a CSS Processor?

Today, writing CSS that exists in the future

The existence of “CSS processors” is primarily to compensate for the shortcomings of CSS development. In the early days, there were no complex logic and functions to write reusable and manageable code, leading developers to face the challenges of difficult management and scalability, especially in large projects where things became even more chaotic. Thus, CSS processors emerged to solve these problems.

By extending the functionality and syntax of CSS through preprocessors, more complex logic and cleaner code can be achieved, such as Variables, Functions, Mixins, Code Nesting, etc., practicing the DRY principle.

Alternatively, post-processors can be used to handle existing CSS to compress, modify, or change the current CSS, such as Import, Minification, Autoprefixer, CSS Nano, etc.

Reasons to Use Preprocessors

Make writing CSS full of possibilities!

  • Write nested CSS without repeating names (Nesting)
  • No need to cram all code into one file (Modules/mixins)
  • Use variables and operators (Variables/Operators)
  • Avoid repeatedly writing the same code (Extend/Inheritance)

In summary, preprocessors help us write CSS better, writing in a preprocessor language (which can be imagined as writing CSS rich in syntactic sugar) and then using the preprocessor to compile it into CSS.

Of course, browsers still only recognize CSS and do not understand the syntax of any preprocessor language. Therefore, when using it, the syntax of the preprocessor needs to be “pre” processed into CSS for use. Although various preprocessors have their own defined logic and syntax, they ultimately all get translated into CSS.

How to Use Preprocessors?

Preprocessors can be installed in a project via package managers or by using existing software like Prepros to achieve the same purpose. However, from a beginner’s perspective, it is recommended to set up and use CSS Preprocessor on Codepen🔗 for practice (free registration available).

Sass is currently the most widely used preprocessor (State of CSS 2021🔗), and it was also one of the first preprocessors to appear. With a large community and learning resources, it is a mature, stable, and powerful preprocessor. Originally written in Ruby, the official recommendation now is to use the new Dart Sass🔗.

There are two syntaxes for writing Sass — SASS or SCSS, where SCSS is closer to the appearance of CSS, using braces and semicolons to nest statements, and the regular CSS also means it is regular SCSS syntax.

Personally, I prefer the visually simpler SASS. If you particularly dislike writing a bunch of {} and ; in CSS, then choose SASS! Aside from that, the only difference is in writing habits; they are still the same thing.

If you are still unclear, the following sections will use Sass as an example of a preprocessor to explain the solutions it provides.

LESS — Leaner Style Sheets

LESS is a preprocessor written in Javascript and is undoubtedly a major competitor to Sass. However, since Bootstrap switched its preprocessor to Sass in version 4, it has seen less usage.

Stylus

Stylus is a preprocessor written in Node JS, which is more niche and has a smaller user base, but it still occasionally appears, so it’s worth mentioning here.

Finally, why you might not need a preprocessor

After explaining the benefits of preprocessors, it’s also important to understand the situations where you shouldn’t use them.

Non-native

The world of front-end development is constantly changing, and adding unnecessary dependencies to a project is not a good thing; non-native code may be replaced by native code one day, meaning that some features provided by certain preprocessors may be caught up with in the future, potentially requiring a code refactor.

Higher level of abstraction

Preprocessors apply CSS at a higher level of abstraction, which may require additional costs for those who do not understand it to maintain your code, creating a more complex development environment and requiring extra time to learn.

Project is not very large

Using the above features requires installation, configuration, and learning, so it might be better to just start writing CSS directly.

Conclusion

Ultimately, should you use a preprocessor? Which one should you use? It depends on team and individual preferences or the scale of the project. Improving CSS, any preprocessor can be effective.

References