Sass less comparison. LESS vs SASS preprocessors: which is better to use where?

From the author: First of all, what is a preprocessor? In short, a preprocessor is a program that modifies data to suit the input requirements of another program. CSS preprocessors are scripting language, expanding the capabilities of conventional CSS variables, nesting rules, functions and logical blocks.

Why should I use it?

Often you will find yourself in a situation where you have to use same value for a specific property in different places. For example, you first specified red as the primary color of the site. Then you need to change it to green.

With variables, you don't have to search and replace every mention of red in styles. You define the value of a variable once, for example "primary color", and then use that variable as the value.

The primary color value changes in one place. You can also import CSS file s from other sources without thinking about the number of network requests, since they can all be combined into one file before compilation.

Thanks to the nested nature of CSS preprocessors, you'll get compact code with the same result. LESS and SCSS are based on the DRY principle, which stands for “Don’t repeat yourself” or “don’t repeat yourself.”

Preprocessors. Quick start

What's wrong with LESS?

The network is already full of discussions about which is better: LESS or SCSS. Therefore, I will not cover both topics in detail. Instead, I'll talk about the little problems I had with LESS.

SCSS uses the $ symbol to define variables, while LESS uses the @ symbol. Since CSS also uses the @ symbol for media queries, imports, and keyframe animations, this can be confusing for developers.

The $ symbol is not used in CSS. The @ symbol is present in SCSS, but it is used for the @if , @else , @each , @for and @while directives.

While this scenario is not realistic for everyone, it is better to use different IDs to separate elements.

SCSS supports traditional logical expressions like if/else, blocks and loops. Guarded mixins in LESS are easier on the eye, but harder to understand.

Can be done using LESS...

...or just using SCSS.

LESS defines only one guarded mixin. Therefore, you cannot simply pass a second argument and process it in the same mixin, duplicating the code for all possible scenarios. In fact, LESS (less) is more (pun intended).

I know it's possible to shorten the code by using augmented values ​​as property names for this case, but the problem is that I can't conditionally map two different parts of the same mixin to LESS.

There are more headaches with this code...

Preprocessors. Quick start

Learn the basics of using Less and Sass preprocessors with complete zero in less than 2 weeks

...than with this.

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

While this is my personal opinion, I think SCSS generally handles calculation values ​​and mathematical values ​​better.

What's wrong with this?

LESS, on the other hand, is much more complex. For example, when I use it, I'm not trying to do calculations. But even if I did, since when does 100% minus 50px equal 50%?

LESS, why are you ignoring values ​​with change units?

Why are you making me learn your crutches when I already know CSS?

And one last thing. Thanks to the LibSass project, SCSS has many wrappers for other languages, such as C, Go, PHP, Python, Dart, etc.

Why did we decide to abandon LESS in favor of SCSS?

While we were developing JotForm Cards, we needed to pre-process variable values ​​- pre-compiling and server-side caching at the same time; and all this had to be done perfectly.

We wanted users to be able to customize appearance forms So that any changes are instantly and simultaneously displayed and cached on the server. For the sake of our users, we didn't want to run a LESS client shell because that would require computing power client - and a lot of things can go wrong.

We did not start the development cycle with the goal of moving from LESS to SCSS. But halfway through dealing with these minor issues, the lack of a decent wrapper for LESS was the last straw.

However, the differences between LESS and SCSS are less important than what they have in common. In the end, it doesn't matter which preprocessor you use, as long as you use it.

Trying to manage a huge project with one CSS file and traditional CSS structure much more difficult than using a preprocessor with a couple of problems.

“and a completely logical question arose: “What is the difference between SASS and SCSS?” The topic is interesting, so let's figure it out.

When we talk about Sass, we usually mean the preprocessor and the language as a whole.

However, using Sass (preprocessor) we can use two different syntaxes:

• Sass(indentation) ;
• SCSS (CSS-like syntax).

A little history

Sass was originally part of another preprocessor, Haml, which was invented and written by Ruby developers.

So Sass styles used a Ruby-like syntax, no parentheses, no semicolons, and no strict indentation, like this:

// Variable!primary -color= hotpink // Primary =border-radius(!radius) -webkit-border-radius= !radius -moz-border-radius= !radius border-radius= !radius .my-element color= !primary -color width= 100% overflow= hidden .my-other-element +border-radius(5 px)

Compared to CSS syntax there is a noticeable difference.

The variable is specified via ! , not $ , value assignment symbol = , not :.

But this is how Sass looked before version 3.0, released in May 2010, which introduced an entirely new syntax called SCSS or Sassy CSS.

His goal was to bring Sass syntax closer to CSS, making it more compatible with CSS:

// Variable $primary -color: hotpink; // Mixin @mixin border-radius($radius ) ( -webkit-border-radius: $radius ; -moz-border-radius: $radius ; border-radius: $radius ; ) .my-element ( color: $primary -color; width: 100%; overflow: hidden; .my-other-element ( @include border-radius(5 px); )

SCSS is definitely closer to CSS than Sass. The Sass developers worked hard to make both syntaxes closer to each other by replacing ! (variable sign) and = (assignment sign) on $ and: from CSS.

So when starting a new project, you may be wondering what syntax to use. Let me help you make a decision.

Pros of Sass Indented Syntax

Although this syntax may seem a little strange to you, it has several interesting moments. First of all, it is shorter and easier to type. There are no parentheses or semicolons, they are not needed.

It doesn't need @mixin or @include when a simple symbol: = and + is enough.

Sass also has clean coding standards due to its use of indentation. Since incorrect indentation can break the entire .sass stylesheet, the first step here is to ensure that the code is clean and properly formatted.

There is only one way to write Sass code: write it correctly.

Don't forget that indentation has a boolean value in Sass. When a selector block indentation is applied, it means it is a nested selector.

For example:

.element-a color: hotpink .element-b float: left ... outputs the following CSS code: .element-a ( color : hotpink ; ) .element-a .element-b ( float : left ; )

The simple fact of shifting .element-b one level to the right means that it is child element from .element-a , which changes the resulting CSS code. So, be careful with indentations!

I believe that the indentation-based syntax will appeal more to a team working primarily with Ruby/Python than to a team of PHP/Java programmers (but this is not certain).

Pros of SCSS syntax

Firstly, it is fully CSS compatible. This means that you can rename a CSS file to .scss and it will work as if nothing had happened.

Making SCSS fully compatible with CSS has always been a priority for Sass support since the release of SCSS, and in my opinion this is a strong point.

They also try to keep an eye out for what might become valid CSS syntax in the future and implement it (hence @directives ).

Since SCSS is compatible with CSS, it requires virtually no additional training. The syntax is pretty much the same: after all, it's just CSS with some extras.

This is important for new developers so they can quickly start coding without knowing much about Sass.

It is also more readable since the specific constructs already make sense. When you see @mixin , you know it's a mixin declaration; when you see @include , you know it's a mixin call.

There are no strings attached and everything makes sense without interpretation.

Also almost everything existing tools, plugins and demos for Sass are developed using SCSS syntax. This syntax is becoming more and more oriented towards professionals and is chosen by them by default (if it is not the only possible one).

Mainly due to the reasons stated above. For example, it's becoming increasingly difficult to find highlighting for pure Sass indented syntax; generally only SCSS backlighting options are available.

Conclusion

The choice is yours anyway, but unless you have a really compelling reason to use indented syntax, I would strongly recommend using SCSS over Sass. It's not only easier, but also more convenient. If you are a complete beginner, then SCSS is what you need. The similarity to CSS will not scare you away from learning layout using preprocessors. But after that you can consider the option using Sass in your projects. The main thing is not to be afraid to use new technologies in your work!

P.S. Please note that Sass is never abbreviated from capital letters, regardless of whether it is a syntax or a programming language. While SCSS is always indicated in capital letters.

I like the SASS syntax more than SCSS for its brevity. But the massive nesting of styles in SASS can quickly eliminate the benefits of its brevity. In any case, the difference between SASS and SCSS is not fundamental. LESS turned out to be closer to SCSS than to SASS. And, in general, it’s the same thing. There are not many differences, but a couple of them fundamentally change the balance of power.

1. LESS - can client-side using JS.

More precisely, it’s not that he can, he’s designed for this. Common practice for using LESS code:

It was then that the ability to compile on the server (both js and ruby) was added to it.

At first glance it seems like a strange property. Why compile on the client side if you can compile perfectly on the server and serve ready-made compressed CSS as we are used to with SASS?

The reason becomes clear after studying the nondescript very last lines of the LESS documentation:

@height: `document.body.clientHeight`;

Such a small lonely line provides opportunities that layout designers have only dreamed of since the beginning of mastering styles. Calling a client-side Java script from CSS and taking into account actual browser settings when creating styles.

That is, we now have the opportunity to first load the DOM, and then create special CSS for it directly on the client side. Then think for yourself what opportunities this opens up.

Whether your project needs this is a different question. It is clear that everyone is accustomed to client uncertainty/independence and layout in the style of “we do it universally so that it will more or less be shown to everyone at all resolutions.” But this is not a reason to forget that now such an opportunity exists and with it you can do, for example, a very flexible layout.

2. LESS, unlike SASS/SCSS, has no logic.

There is no if/then, for, etc. in LESS. Although, considering that JS is easily built into it, I think it’s quite possible to screw in the logic. I haven't tried it.

3. Mixing is easier in LESS + you can mix classes.

I really liked the fact that in LESS you can include properties of other classes in the definition. The class itself is a mixin. This is another feature that SASS/SCSS does not have. You can include in LESS regular CSS file and use its classes to define your properties. For example:

Wrap (
text-wrap: wrap;
white-space: pre-wrap;
white-space: -moz-pre-wrap;
word-wrap: break-word;
}
pre ( .wrap )

Resume

With the exception of the 1st point, the difference is not great and the choice is greater for the amateur.

For me personally, LESS looks more attractive because of its simplicity. I have never needed cycles and conditions in styles before. Classic utilities like “box-shadow, linear-gradient, darken” are available in LESS.

Yes, many ready-made libraries have already been written for SASS (