LESS versus SASS overview
Yesterday I spent half a day on a detailed study of LESS and its difference from the SASS / SCSS used by us.
SASS syntax impresses me more than SCSS for its brevity. But the large nesting of styles in SASS can quickly eliminate all the advantages of its brevity. In any case, the difference between SASS and SCSS is not fundamental. LESS was closer to SCSS than to SASS. And, in general, it is the same. There are not many differences, but a couple of them fundamentally change the balance of power.
')
More precisely, it is not that it can, it is designed for this. The usual practice of using LESS-code:
This is then already screwed to it the ability to compile on the server (and js and ruby).
At first glance, some strange property. Why compile on the client side, if you can perfectly compile on the server and give the ready-made already tight CSS like we used to with SASS?
The reason becomes visible after studying the most inconspicuous most recent lines of LESS documentation :
This is such a small lonely line that gives the possibilities that designers only dreamed of from the beginning of mastering styles. Calling client-side java-script from CSS and taking into account the actual parameters of the browser when creating styles.
Ie, we have the opportunity to first load the DOM, and then create special CSS directly on the client side. Further think what opportunities this opens.
Does your project need this other question? It is clear that everyone has become accustomed to client uncertainty / independence and layout in the style of “we do universally, so that it is more or less shown to everyone at all resolutions”. But this is not a reason to forget that now there is such an opportunity and with it you can do, for example, well, very rubber layout.
In LESS there is no if / then, for, etc. Although, given the fact that JS is easily embedded in it, I think logic is quite possible to tie. I have not tried.
I liked very much the fact that in LESS one can include the definition of a property of other classes. The class itself is a mixin. This is another feature that is not in SASS / SCSS. You can include a regular CSS file in LESS and use its classes to define its properties. For example:
With the exception of the 1st point, the difference is not great and the choice is great amateur.
For me personally, LESS looks more attractive because of its simplicity. I have never needed cycles and conditions in styles. There are classic box-shadow, linear-gradient, darken 'utilities in LESS.
Yes, many ready-made libraries are already written under SASS ( compass , bourbone and a fairly wide community), but under LESS there is the same Twitter Bootstrap and this is more than enough.
PS Found the comparison star SASS vs LESS and with it discovered a curious service of reasoned comparisons wrangl.com
SASS syntax impresses me more than SCSS for its brevity. But the large nesting of styles in SASS can quickly eliminate all the advantages of its brevity. In any case, the difference between SASS and SCSS is not fundamental. LESS was closer to SCSS than to SASS. And, in general, it is the same. 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 is not that it can, it is designed for this. The usual practice of using LESS-code:
<link rel="stylesheet/less" type="text/css" href="styles.less"> <script src="less.js" type="text/javascript"></script> This is then already screwed to it the ability to compile on the server (and js and ruby).
At first glance, some strange property. Why compile on the client side, if you can perfectly compile on the server and give the ready-made already tight CSS like we used to with SASS?
The reason becomes visible after studying the most inconspicuous most recent lines of LESS documentation :
@height: `document.body.clientHeight`;This is such a small lonely line that gives the possibilities that designers only dreamed of from the beginning of mastering styles. Calling client-side java-script from CSS and taking into account the actual parameters of the browser when creating styles.
Ie, we have the opportunity to first load the DOM, and then create special CSS directly on the client side. Further think what opportunities this opens.
Does your project need this other question? It is clear that everyone has become accustomed to client uncertainty / independence and layout in the style of “we do universally, so that it is more or less shown to everyone at all resolutions”. But this is not a reason to forget that now there is such an opportunity and with it you can do, for example, well, very rubber layout.
2. LESS, unlike SASS / SCSS, has no logic.
In LESS there is no if / then, for, etc. Although, given the fact that JS is easily embedded in it, I think logic is quite possible to tie. I have not tried.
3. In LESS it is easier to mix + mix classes.
I liked very much the fact that in LESS one can include the definition of a property of other classes. The class itself is a mixin. This is another feature that is not in SASS / SCSS. You can include a regular CSS file in LESS and use its classes to define its 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 great amateur.
For me personally, LESS looks more attractive because of its simplicity. I have never needed cycles and conditions in styles. There are classic box-shadow, linear-gradient, darken 'utilities in LESS.
Yes, many ready-made libraries are already written under SASS ( compass , bourbone and a fairly wide community), but under LESS there is the same Twitter Bootstrap and this is more than enough.
PS Found the comparison star SASS vs LESS and with it discovered a curious service of reasoned comparisons wrangl.com
Source: https://habr.com/ru/post/130886/
All Articles