Proposal - switch to node-sass

[cheapsteak]

They are syntax-compatible for 95% of use cases

Less's calc is defective

width: calc(100% - 100px)

This gets compiled to: with LESS: [demo]

width: calc(0%); /*wat*/

with SCSS: [demo]

width: calc(100% - 100px);

You have to do escape the string in less

width: ~"calc(100% - 100px)";

This is mental and has tripped at least one developer on each project I've had

Mixin definitions are different, but not by much. (Haven't really had cause to use mixins since autoprefixer)

Loops are different. Haven't had to use a loop for a long time either, but if you need to, sass's loop syntax is, imo, better. Sass's has for loops and each loop that can loop through indexes or arrays of strings Less uses recursion for loops and can only loop through numbers.

Less was the first viable css preprocessor in node, back when using sass meant either you had to install ruby, or settle for the (at the time) much less powerful libsass. But libsass now has 98.53% feature parity with ruby sass (node-sass is a wrapper for libsass).

So to sum up, I propose to switch to node-sass (or at least have trial runs where projects are allowed to use node-sass instead of less) because its calc isn't defective, the language features we rarely use are different but not by much, and sass is the industry standard.

[mikkoh]

Can you see other reasons to switch besides the one compilation error?

One thing I like in sass is scoping, works far better than less.

[cheapsteak]

On one hand this is still in the same vein of one far-reaching error that could happen any time you're doing math with variables that have units:

// vars.less
@contentWidth: 100%;
@sidebarWidth: 30px;

// component-foo.less

div {
  width: @contentWidth - @sidebarWidth;
  background-color: red;
}

Less, for some reason, converts the px to % and gives you 70% Sass errors and warns you doing about math on incompatible units

On the other hand, seeing as switching-cost seems minimal (I don't think anyone frequently uses it for more than variables and nesting?), why not provide the option to use the one that doesn't do bug-prone math :D

Sass also has placeholder selectors and the loops are nicer to write (for loops and each loops instead of recursive loops)

Here's the creator of Bootstrap's reasoning for switching to SCSS for Bootstrap 4:

Popularity is a big one for me. The former seems pretty clear to me—Sass is more widely known and used. Plus, there's more of a community (or communities) around it with all the Sass conferences and meetups. Less, not so much it seems.

I like Sass's syntax for things, too. The explicit @mixin name-of-mixin {} for example is nice in that it doesn't look like malformed CSS when you do .element { .another-element(); } in Less. That also makes it easier to explain to beginners in my mind. Although I do really like that "everything is a mixin" in Less with that, being explicit in your CSS is kinda what makes good CSS good.

https://www.designernews.co/comments/147269

Here's an excerpt from a company that converted their product from Less to Sass

Why? Before we get to what we learned, your first question—a legitimate one—should be, “Why bother?” We already benefitted from variables and mixins, @imports and color functions. Certainly, Sass has a number of features Less lacks, such as maps and functions, but we made it this far without them. Two major reasons for switching stand out:

• Community: Search github for lib extension:scss, then search for lib extension:less. As of this writing, the results are clear: 120,234 SCSS files, 29,449 Less files. Switching offers access to a wider array of good ideas and a larger open-source pool to swim. Even the popular Bootstrap library, one of the reasons Less has remained viable, has announced it is switching to SCSS.
• Speed: Libsass rocks. The build time for our styles improved by over 500%. While Libsass has not yet caught up with the latest version of the Sass spec, we do not feel we are missing anything.

http://sproutsocial.com/insights/less-to-sass/

So there are other reasons, but I don't really care too much about popularity, community, loops, and the probably negligible speed difference; it's mainly the bug-prone math, everything else is window dressing (although placeholder selectors are nice :smile: )

They're also so similar in syntax for regular usage I don't think it'd be difficult for a dev to dive into a project in scss vs less, and any juniors coming in would be more likely to already be familiar with Sass <- hackeryou

[miguelmoraleda]

@mikkoh A good reason is the Google's guidelines, they don't accept less, so if the swap is painless for us, it is a very nice to have.