Sass, too, supports Less’s mixin model. Sass can include any block as a mixin with the @extend directive (http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#ex...). Basically, if a block is going to be used in the HTML as well as elsewhere, you write it normally and then include it with @extend. If a block is only going to be included in other styles, you write it with @mixin and then include it with @include. I think Sass’s approach is better because it’s more flexible – if a style isn’t going to be referenced in the HTML, it doesn’t clutter up the CSS because it is hidden with @mixin. And if you like Less’s approach better you can just use @extend everywhere.
The main reason I prefer Sass is the indent-based and semicolon-less Sass syntax (as opposed to the SCSS syntax). I find that that syntax’s advantages greatly outweigh its few weaknesses.
Comments
relevant documentation links on your point “c)”:
http://lesscss.org/#-mixins
http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#im...
Sass, too, supports Less’s mixin model. Sass can include any block as a mixin with the @extend directive (http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#ex...). Basically, if a block is going to be used in the HTML as well as elsewhere, you write it normally and then include it with @extend. If a block is only going to be included in other styles, you write it with @mixin and then include it with @include. I think Sass’s approach is better because it’s more flexible – if a style isn’t going to be referenced in the HTML, it doesn’t clutter up the CSS because it is hidden with @mixin. And if you like Less’s approach better you can just use @extend everywhere.
The main reason I prefer Sass is the indent-based and semicolon-less Sass syntax (as opposed to the SCSS syntax). I find that that syntax’s advantages greatly outweigh its few weaknesses.