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

Question:

It's hard to see people writing "old fashioned CSS" these days because of the preprocessors that make writing easier by removing code repetitions, and simplifying syntax.

I would like to understand what differences (syntax and any advantages/disadvantages) they have, if they fulfill the same role, or if they have a different approach.

Answer:

if they play the same role, or if they take a different approach.

That phrase of yours sets the tone for your question. I will try to base my answer on both of these points.

Do they play the same role?

Basically yes. The role of the preprocessor is to provide the necessary tooling to be able to work around some of the recurring issues of the latest CSS specification . There is already a draft for the next one, which promises to make our life much easier, and when most browsers have already implemented it, the pre-processor scenario will, for sure, change a lot. Remember that SASS , LESS , Stylus is intended to generate .css file(s) that meet the third specification. So when the CSS 4 selectors arrive, your code will continue to work without a problem, but some of the preprocessor features will become obsolete. For the sake of curiosity, there are things like Post CSS , which are intended to allow the developer to write code containing the new selectors and sort of downgrade to CSS 3 . I'm not going to talk about it because that's not the focus of the answer, but here's an article that brings up the basics.

It is interesting to note that this scenario is changeable. Tomorrow, CSS 4 will be there, and there have been preprocessors that will solve problems that should be fixed in spec 5, and so on. Some of the main things that preprocessors facilitate today are

  1. Variables, loops , conditionals, …

    CSS is not a programming language. CSS is a style sheet, ie, a series of rules that must be followed for the presentation of tags . That sheet is a list, and the browser interprets it as such. This means that without the pre-processor, when it was necessary to assign the same color to different selectors, you had to wiggle to make a smart move blending inheritance concepts ( inherit ) and cascading, but eventually had 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 making this change manually. Or else, sprites . At the company I work for, we use sprites to serve our images, and doing the background-position calculations by hand only serves to torment the intern. With preprocessors, you can solve this with a loop .

  2. Maintenance

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

  3. Frameworks

    There are frameworks built around preprocessors that do great things. susy is an agnostic grid framework , built on top of SASS . Compass , in addition to working very well with vendor prefixes , can create sprites for you from an image. Good, no?

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

Do they have a different approach?

Yes. Specifically talking about the top 3:

  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 Python . It is the most popular of the 3 and has a number of frameworks available. It's worth pointing out that the Ruby SASS and LibSASS are slightly different .

  2. LESS

    It was originally written in ruby , but later ported to JavaScript . It can work server-side , like a node module, it's the only one of the 3 compatible with Rhino (as far as I know) and, most amazingly, it can be used client-side . I don't know why anyone would do something like that, since it's even more burdensome on the client side, and I can't see any good points in that approach. If anyone knows of an advantage, say so.

  3. Stylus

    Also written in JavaScript , Stylus has the most flexible syntax of the three. this code

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

    compile for

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

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

In terms of variables, SASS requires them to start with the $ character. LESS , in turn, determines the @ character. Stylus is (again) more flexible, and allows for pretty much anything (be careful with reserved words). The only requirement is a space between the equals sign and the variable name, and between the equals sign and the value. That is

minha_cor = blue

is allowed, while

minha_cor=blue

do not.

For the rest, they are similar to each other, as they have the same purpose. Of course, each one of them has its own methods and its peculiarities, which can make them more or less viable for a given project. In this link you will find a comparison made almost exclusively on syntax. And in the latter , a table comparing almost everything between the 3. If you are thinking of migrating from one preprocessor to another, get this table

Post Views: 0
Scroll to Top