Important differences between Sass and SCSS. What is Less and Sass


  • Translation

“Which preprocessor language should I use for CSS?” is a very pressing issue in Lately. I've been asked this in person a few times, and it seems like every couple of days the question comes up online. It’s very nice that the conversation moved from the topic of the pros and cons of preprocessing to a discussion of which language is the best. Get to work!

To be brief: SASS.

A slightly expanded answer: SASS is better on all counts, but if you are already happy with LESS - that's cool, by the way at least You have already simplified your life by using preprocessing.

Training schedule with Ruby and the command line The only point is syntax. To compile the files you create, you should use an application like CodeKit. You must know the basics of Ruby or command line or something else. You should probably know this, but you don't have to, so it doesn't really matter.

Winner: none.

CSS3 to the rescue With any of the languages, you can create your own mixins to make life easier with prefixes. So there is no winner here. But do you know how to avoid updating these prefixes in your projects? (No, you don't know). Also, you most likely won't have to update your own file with impurities. SASS allows you to use Compass, whose auto-updates make prefix problems a thing of the past. Of course you can update software and compile it from time to time, but this trivial task and you shouldn’t get hung up on it.

So what it all boils down to is this: SASS has Compass and LESS doesn't. In fact, everything is a little more complicated. All attempts to create a project like Compass for LESS have failed. The point is that LESS is not a strong enough language to do this correctly. A little more detail below.

Winner: SASS

Language Features: Logic/Loops LESS allows you to create "secure mixins". These mixins will only take effect if the condition is true. Let's say you want to change the background color, which will depend on the current text color. If the text color is "light enough" you'll probably want to make the background dark. If it's "dark enough" you'll want a light background. This way you end up with a mixin split into two parts with these "guards" that ensure that only one of them gets executed.

LESS
.set-bg-color (@text-color) when (lightness(@text-color) >= 50%) ( background: black; ) .set-bg-color (@text-color) when (lightness(@text -color)< 50%) { background: #ccc; }
After use you will get a suitable background:

LESS
.box-1 ( color: #BADA55; .set-bg-color(#BADA55); )
It's very simple, but the essence, I hope, is clear. You can do much cooler things than this. LESS also allows self-referencing recursions whose mixins can call themselves with updated values.

LESS
.loop (@index) when (@index > 0) ( .myclass ( z-index: @index; ) // Call itself .loopingClass(@index - 1); ) // Stop loop .loopingClass (0) () // Outputs stuff .loopingClass (10);

This is where the logic/loops in LESS end. SASS has up-to-date logical and cyclic operators. if/then/else, for loop, while loop and each loop. No tricks, real programming. SASS is a fairly robust language that makes possible use Compass.

For example, Compass has a background mixin that is so powerful that you can throw whatever you want into it and end up with exactly what you want. Pictures, gradients and any combination of them, separated by a comma - and you get desired result(including prefixes and everything else).

A laconic piece of code:

SCSS
.bam ( @include background(image-url("foo.png"), linear-gradient(top left, #333, #0c0), radial-gradient(#c00, #fff 100px)); )
This code turns into the monster below (which, unfortunately, is needed for cross-browser compatibility):

CSS
.bam ( background: url("/foo.png"), -webkit-gradient(linear, 0% 0%, 100% 100%, color-stop(0%, #333333), color-stop(100%, #00cc00)), -webkit-gradient(radial, 50% 50%, 0, 50% 50%, 100, color-stop(0%, #cc0000), color-stop(100%, #ffffff)); background : url("/foo.png"), -webkit-linear-gradient(top left, #333333, #00cc00), -webkit-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo .png"), -moz-linear-gradient(top left, #333333, #00cc00), -moz-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo.png"), - o-linear-gradient(top left, #333333, #00cc00), -o-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo.png"), -ms-linear-gradient( top left, #333333, #00cc00), -ms-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo.png"), linear-gradient(top left, #333333, #00cc00) , radial-gradient(#cc0000, #ffffff 100px); )
Winner: SASS

Winner: LESS

@extend concept Let's say you created a class with a certain set of styles. Then you will need to create another one, which will be like the previous one, but with some additions. LESS allows you to do it like this:

LESS
.module-b ( .module-a(); /* Copies everything from .module-a down here */ border: 1px solid red; )
In essence, this is an ordinary “include”. You can also use this insertion in SASS, but it's better to do it using @extend . @extend doesn't just copy the styles from .module-a to .module-b (which produces file bloat), it changes the name of the .module-a selector to .module-a, .module-b in the compiled CSS (which is more efficient way).

SCSS
.module-a ( /* A bunch of stuff */ ) .module-b ( /* Some unique styling */ @extend .module-a; )
Compiles to:

CSS
.module-a, .module-b ( /* A bunch of stuff */ ) .module-b ( /* Some unique styling */ )
Do you see this? SASS overrides selectors, which is a more efficient way.

Winner: SASS

Variable handling LESS uses @, SASS uses $. The dollar sign is not used in CSS, but @ is not. It is used to declare @keyframes or @media blocks. You may think that using one or another special character is a matter of taste, but I think that SASS has an advantage here precisely because it does not confuse the basic concepts.

SASS has a strange property - if you override a "global" variable with a "local" one, the global variable will take on its value. A little strange.

SCSS
$color:black; .scoped ( $color: white; color: $color; ) .unscoped ( // LESS = black (global) // SASS = white (overwritten by local) color: $color; )
This trick can be useful, but it's not at all intuitive, especially if you're writing in Javascript.

Winner: you have to toss a coin :)

Working with media rules Almost each of us, starting to work with @media rules, adds blocks with them at the bottom home page styles. This works, but leads to style decoupling, like this:

CSS
.some-class ( /* Default styling */ ) /* Hundreds of lines of CSS */ @media (max-width: 800px) ( .some-class ( /* Responsive styles */ ) )
With SASS or LESS you can combine these styles using nesting.

SCSS
.some-class ( /* Default styling */ @media (max-width: 800px) ( /* Responsive styles */ ) )
"respond-to" is a pretty cool SASS technique (check out the code from Chris Eppstein, Ben Schwarz, and Jeff Croft).

SCSS
=respond-to($name) @if $name == small-screen @media only screen and (min-width: 320px) @content @if $name == large-screen @media only screen and (min-width: 800px) @content
Then you can use them very succinctly:

SCSS
.column width: 25% +respond-to(small-screen) width: 100%
Note: to use this technique you will need SASS 3.2, which is currently in alpha, you can install it with gem install sass --pre . I think there should be no doubt that this is a really useful thing in development.

Winner: SASS

Mathematics Basically, the math part of both languages ​​is quite similar, but there are still some oddities in the handling of units of measurement.
For example, LESS will take the value of the first variable as its unit, ignoring all others.

LESS
div ( width: 100px + 2em; // == 102px (weird) )
SASS will let you know clearly and clearly that there is an error hidden here:
Incompatible units: "em" and "px" . Of course, it is a controversial issue which is better - an error or an incorrect value, but personally I am for the former. Especially if you favor variables instead of using numbers, this makes them very difficult to track.

SASS allows you to conduct mathematical operations with "unknown" units of measurement, which may appear until the next update. LESS doesn't allow this. There are even weirder differences, like how SASS multiplies numbers with units, but that's not a topic for today.

Winner: SASS (with a stretch)

What are the main tasks of the preprocessor, and which one to choose: SASS or LESS, we will discuss in this article. First you need to define a preprocessor - what is it? It is a tool or tool that modifies certain code by transforming it through various capabilities. The processor input is code that is described by various syntactic structures. These designs are understandable only to this instrument. It can replace various complex language constructs or, on the contrary, add new ones. The output of the program is lower quality code with deleted constructs.

For better understanding Consider the term preprocessor as an example. The input of this program is code that contains various words, problems, commas and periods. If there is a replacement function keyword in its short form, that is, in an abbreviation, to the full name, then the output will be a sentence with an expanded notation. This is the most primitive understanding of what a preprocessor is. Essentially, it contains more complex commands and capabilities.

So, this program offers various designs for simplicity and speed of development and style support.

Usually the code is aimed at human characteristics:

  • Readability.
  • Structure.
  • Performance.

    • Also, when considering preprocessors, programmers are faced with the concept of syntactic sugar. These are some additions to the programming language that do not affect any gain. additional features, but improve readability.

    Main types

    The most common options are LESS, SASS and Stylus. So, as already defined above, the advantages of using such tools are the improvement of text content, structure and productivity. However, few developers use such programs in their work, as they believe that working with them is complicated and many functions are not clear.

    The program is the most popular in this problem. This program was developed in 2009 by a team of programmers. It has all the functionality on basic level. The main disadvantage is the lack of conditional structures and loops. Main advantage of this instrument– it is clear and easy to use, it functionality can be extended with various plugins.

    Syntactically Awesome Style Sheets

    SASS is the most powerful preprocessor. It was developed by a whole team of programmers. It was founded in 2007 as a module for HAML and is also written in Ruby (there is a C++ port). It also has a wider range of features compared to other programs. To extend the capabilities of Syntactically Awesome Style Sheets, you can use the powerful Compass library. The SASS program has two syntax options: Sass and SCSS.

    This is the youngest and most promising instrument. It was founded in 2010. The Stylus preprocessor is the most convenient and extensible preprocessor.

    Usually the programmer is already working with LESS. Any file is considered a valid LESS file. In this case, there is no need for a file extension. When taking regular CSS code, let's put it in a file with the same name, but with the .less extension. In fact, an identical file was received without errors and with exact content. The only difference between the files was the presence of empty lines after the selectors. Thus, when using this tool, compilation time is much less. Therefore the action this tool directed to specific goals, building a convenient structure. This can be done with regular CSS, but it will be less convenient.

    Main factors in choice

    According to functional characteristics Sass is definitely better than other programs in many ways. But if the work is already done using Less, there is no point in changing it. As mentioned above, SASS allows you to use Compass, which makes working with prefixes easier. Other programs do not have a Compass project because the tool's language is quite complex. SASS has logical and cyclic operators. The LESS website is beautiful and user-friendly compared to other websites.

    When working with @media rules, the programmer adds blocks with them at the bottom of the styles page. This leads to a disconnect in styles. Less and Sass are both tools that solve this problem, and the math behind them is generally similar. In terms of speed, both preprocessors have good performance.

    The developers of both options continue to improve them further.

    According to reviews and comments from programmers, both tools can be used with equal capabilities. Syntactically Awesome Style Sheets according to some sources has more low speed compared to others. Some consider Stylus to have surpassed both preprocessors today.

    So, exact solution There is no question about using Less and Sass, since they both have good properties and functionality. Therefore, the choice is determined by the goals and objectives of the programmer.

    I've been writing a lot about Sass lately, but from some recent comments I realized that not everyone has a clear understanding of what Sass is. Let's be a little clearer:

    When we talk about Sass, we usually mean the preprocessor and the language as a whole. We say, for example, “we use Sass”, or “here is a Sass mixin”.

    Meanwhile, Sass (the preprocessor) allows two different syntaxes:

    • Sass, also known as indented syntax;
    • SCSS, CSS-like syntax.
    Story

    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 // 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 +border-radius(5px)

    As you can see, compared to regular CSS, the difference is noticeable! Even if you are a Sass (preprocessor) user, you can see that this is very different from what we are used to.

    A variable is denoted by ! , not $ , value assignment symbol = , not : . Quite unusual.

    But this is what Sass looked like until 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(5px); )

    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 cover this topic and explain the pros and cons of each syntax.

    Pros of Sass Indented Syntax

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

    Even better! It doesn't need @mixin or @include when it's enough simple symbol: = and + .

    Also, Sass syntax provides clean coding standards due to the 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.

    But be careful! 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!

    As an outsider, I think that an indentation-based syntax would probably appeal more to a team working primarily with Ruby/Python than a team of PHP/Java programmers (though I'd love to hear opinions to the contrary).

    Pros of SCSS syntax

    For starters, it is fully CSS compatible. This means you can rename CSS file in .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 all 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 in any case, but if you don't really have good reasons use indented syntax, I would strongly recommend using SCSS rather than Sass. It's not only easier, but also more convenient.

    I tried the indentation syntax once and liked it. Especially its brevity and simplicity. I was about to move all my working code to Sass, but at the last minute I changed my mind.

    I'm glad I didn't take this step because I would now have a very difficult time working with some tools if I used the indented syntax.

    Also, 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 denoted in capital letters. Want to know why? Check out SassnotSASS.com!

    The translation of the article “What’s the Difference Between Sass and SCSS” was prepared by the friendly project team

    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 a regular CSS file in LESS 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 )

    Summary

    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 (

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

    When we're talking about When we talk about Sass, we generally mean the preprocessor and the language in general.

    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)

    There is a noticeable difference compared to CSS syntax.

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

    But this is what Sass looked like until 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 some interesting points. 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 a child of .element-a , causing the resulting CSS code to change. 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 all 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 then you can consider 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 referred to by an all-caps abbreviation, whether it is a syntax or a programming language. While SCSS is always indicated in capital letters.
    

    2024 gtavrl.ru.