What are the structural and syntax differences between Sass, Less and Stylus?

Question

Nowadays it’s hard to see people writing "old-fashioned CSS" because of pre-processors that make it easy to write by removing code repeats, and syntax simplification.

I would like to understand what differences (of syntax and possible advantages/disadvantages) they have, whether they play the same role, or whether they have a different approach.

Answer 1

whether they fulfil the same role, or whether they have a different approach.

This phrase of yours sets the tone of your question. I will try to base my answer on both points cited.

They play the same role?

Basically, yes. The role of the preprocessor is to provide the necessary tooling so that it is possible to bypass some problems recurrent of latest specification of the CSS. There already exists a draft for the next, which promises to make our life a lot easier, and when most of the browser already implemented, the pre-processor scenario will certainly change a lot. Remember that SASS, LESS, Stylus has as purpose to generate file(s) .css which comply with the third specification. Then, when the selectors of the CSS 4 arrive, your code will continue to work without any problem, but some of the Features pre-processors will become obsolete. For the sake of curiosity, there are things like Post CSS, whose intention is to allow the developer to write code containing the new selectors and make a sort of downgrade to the CSS 3. I’m not going to talk about it because that’s not the focus of the answer, but here is an article that brings the basics.

It is interesting to note that this scenario is changeable. Tomorrow, the CSS 4 will be there, and there were preprocessors that will troubleshoot which should be corrected in specification 5, and so on. Some of the main points that pre-processors facilitate today sane

1. Variables, loops, conditional, ...

   CSS is not a programming language. CSS is a style sheet, i.e., a series of rules that must be followed for the presentation of tags. That sheet is a list, and the browser interpret it as such. This means that without the preprocessors, when it was necessary to assign the same color to different selectors, you had to roll to make a smart move by mixing the concepts of inheritance (inherit) and cascading, but eventually would have to declare a color: #f09363 at various points in your code. And eventually those values change, and then you pay for all your sins by manually making that change. Or else, sprites. In the company I work, we use sprites to serve our images, and calculate the background-position at hand only serves to torment the intern. With pre-processors, can solve this with a loop.

2. Maintenance

   The above examples already serve to show that the CSS can become a monster at maintenance time. Preprocessors make this process much less painful.

3. Frameworks

   There are frameworks built on pre-processors that do great things. The Susy is a framework of agnostic grids, built upon the SASS. The Compass, besides working very well with vendor prefixes, can create sprites for you from an image. Good, no?

The list of advantages is great, but there are even people saying that you should not use them. Of course this varies from person to person. The fact is that the idea of all preprocessors is the same: make life easier for the developer. That list has 10 different preprocessors, in addition to the 3 that are the focus of the question. If you analyze each of them, you will see that the proposal is the same.

Have a different approach?

Yes. Speaking specifically of the 3 main:

1. SASS

   SASS is written in ruby, and has two different syntaxes, known as .scss and .sass. The first is equivalent to .css, and the second is an indented language, like the Python. It is the most popular of the 3 and has a number of frameworks available. It is worth pointing out that the versions of Ruby SASS and of LibSASS are slightly different.

2. LESS

   It was originally written in ruby, but later ported to the JavaScript. Might work server-side, as a module of node, is the only one of the 3 compatible with Rhino (as far as I know) and, the most amazing, can be used on client side. I don’t know why anyone would do something like that, since it makes the client side even more burdensome, and I can’t see any positive side to that approach. If anyone knows of any advantage, let me know.

3. Stylus

   Also written in JavaScript, the Stylus is the most flexible syntax of the three. This code

   p
      color black
   
   span{
      color blue
   }
   
   div
      color: green;
   

   compilation for

   p {
      color: #000;
   }
   span {
      color: #00f;
   }
   div {
     color: #008000;
   }
   

   You can omit the special characters {}, ;, : and make a combination of those omissions Stylus will understand without problems. I, particularly, believe that this is not very smart. If you become complicit with syntax errors in one language, you will end up porting it to another, and basically no other allows this sort of thing.

In terms of variables, the SASS requires them to start with the character $. The LESS, in turn, determines the character @. Already the Stylus is (again) more flexible, and allows virtually anything (beware of reserved words). The only obligation is a space between the equals sign and the variable name and between the equals sign and the value. That is to say

minha_cor = blue

is permitted as long as

minha_cor=blue

nay.

Moreover, they are similar to each other, since they have the same purpose. Of course, each of them has its own methods and its particularities, which can make them more or less viable for a given project. At this link you find a comparison made almost exclusively upon syntax. And in the latter, a tabelona comparing almost everything between the 3. If you think of migrating from one preprocessor to another, get more this table

Answer 2

CSS3 preprocessors are languages for the purpose of helping in creating styles compatible with all browsers and with several resources to help us, especially when we have huge CSS’s.

The most important thing is to recognize the syntax, and lucky for us all these preprocessors use a language similar to each other.

Sass and LESS

Both use standard CSS syntax and this makes it very easy. Sass uses the extension .scss and the LESS uses .less.

The code below works on Sass or LESS.

/* style.scss or style.less */
h1 {
  color: #0565CC;
}

It is important to note that Sass also has an older syntax, which omits semicolons and keys. Although this one is still out there, it’s old and can’t use it beyond this example.

The syntax uses the file extension .sass and looks like this:

/* style.sass */
h1
  color: #0565CC  

Stylus

The syntax for Stylus is much more detailed. Using the file extension .style, Stylus accepts the standard CSS syntax, but also accepts some other variations, colon and semicolon are all optional. For example:

/* style.styl */
h1 {
  color: #0982C1;
}

/* omitor colchetes */
h1
  color: #0982C1;

/* omitir dois pontos e virgular */
h1
  color #0982C1

Using different variations of the same style is also valid, so the following example will compile without errors:

h1 {
  color #0982c1
}
h2
  font-size: 1.2em

Each of the above files will compile to the same CSS. You can use your imagination to see how useful it can be for your project.

With these techniques you will not need to write the same color or pattern several times, using variables you can greatly decrease and simplify your code.

I see no advantage in using an X technique compared to Y, it goes of the programmer’s taste.

But one thing without a shadow of a doubt is the gain over code organization, how you assemble your CSS and work on it.