How We Learned to Stop Worrying And Love The Preprocessors

First of all, what is a preprocessor?

In the most basic sense, a preprocessor is “a computer program that modifies data to conform with the input requirements of another program.” For CSS, a preprocessor is a scripting language that extends the capabilities of regular CSS with variables, nested rules, functions, and logical blocks.

Why you should consider using one

You can use variables and not worry about finding and replacing every color value on your style sheet when it needs to be changed. You can still import CSS files from other sources and not worry about too many network requests since it is possible to pre-combine them at compile time. You can have leaner code and the same output, thanks to the nested nature of CSS pre processors. Both LESS and SCSS are based on the DRY principle which stands for “Don’t repeat yourself.”

How We Learned to Stop Worrying And Love The Preprocessors

What is wrong with LESS?

Since there are already lots of discussions about LESS vs. SCSS, I’m not going to dive deeply into each topic. Instead, I’ll bring up the smaller issues we’ve had with LESS.

  • SCSS uses $ for variable definitions and LESS uses@. Since CSS also uses the @ for media queries and imports and as animation key frames, this can create confusion for the developer. On the other hand, the $ has no meaning in CSS. The@ still exists within SCSS but it’s used for control directives only, such as @if , @else , @each, @for and@while.

The only difference in the first two lines is the single colon while writing LESS.

While this may not be a real world scenario for everyone, having separate identifiers for separate items is always welcome.

SCSS has superior support for more traditional logical statements, such as if/else blocks and loops. Guarded mixins provided by LESS may be easier for the eyes but harder to master.

You can do this with LESS…

…or simply this with SCSS.

Since LESS matches only one of your guarded mixins, you can’t simply pass a second argument and handle it within the same mixin without writing everything twice for every possible scenario. LESS is literally more.

I know this can be shortened by using argument values as property names for this case, but then again, the point is: I can’t conditionally match two different parts of same mixin with LESS.

This is definitely more headache inducing…

…than this.

To achieve same result with LESS, I had to predefine everything, write a mixin, get the index position, iterate it with my own logic until the index value was zero, and call the mixin manually.

Though this is personal preference, I truly feel that SCSS handles calculation values and mathematical values much better overall.

Why? What is wrong with this? LESS, on the other hand, is much more difficult. For instance, when I’m in there, I’m not trying to do math. Even if I was, since when is subtracting 50px from 100% equal to 50%? Why do you ignore unit values, LESS? Why do you make me learn your quirks on top of my already existing CSS knowledge?

And lastly.

SCSS has many wrappers for other languages such as C, Go, PHP, Python or even for Dart and many more thanks to LibSass project.

Why we decided to drop LESS for SCSS?

While we were working on JotForm Cards, our work required us to handle variable values — pre-compiling and server side caching at the same time and it had to be done without a hiccup. Users should be able to customize the look and feel of their forms, and any changes made by the user should be displayed and should be cached on the servers instantly and simultaneously. We definitely did not want to run the client side LESS wrapper for our users sake because that would require the processing power of the client and many things could go wrong.

While our intention was never meant to switch from LESS to SCSS, halfway through the development process, having to deal with these small issues and not being able to find a good wrapper for LESS was the straw that broke the camel’s back.

In the end it does not really matter which pre processor you use as long as you use one. Trying to govern a huge project with a single CSS file with the traditional CSS structure is more horrifying than using a pre processor that comes with a few minor headaches.