Magento 2 LESS versus SASS Decision

Less vs SassMagento 2 natively incorporates LESS, a CSS pre-processor that simplifies the management of complex CSS files. This post explains the decision behind Magento 2 selecting LESS over SASS. (Spoiler: LESS and SASS are very similar but there were good quality LESS pre-processors implemented in PHP when we had to commit for Magento 2, with none yet stable for SASS.)

Acknowledgement: Thanks to  for lots of background material.

Disclaimer: These opinions are my own (except the ones I stole from Vasiliy!) – they do not necessarily represent the opinion of eBay.


Both LESS and SASS are pretty similar and much of the syntax is identical – SASS is however more powerful. Both look like CSS but extend CSS with additional functionality such as nesting, functions, variables, etc. SASS seems to have some more powerful (or at least complex) constructs such as loops. You can use your favorite search engine to find lots of articles on both LESS and SASS so I am not going to get into technical details here. They both make CSS easier to manage and maintain, especially on large projects. And if you had not noticed, Magento is a large project!

One of the changes in Magento 2 with the adoption of a CSS pre-processor is the CSS provided with Magento is now supplied as a library developers can build upon and extend. You can still replace the whole library, and that is OK, but a CSS pre-processor makes it easier to reuse the supplied library.

So Why LESS?

SASS is more powerful than LESS, and appears to be gaining more market share over LESS.  So why did Magento 2 choose LESS? Sorry, a boring pragmatic reason:

  • At the time we had to commit to a technology, there were several stable LESS pre-processors available in PHP, but no (stable) PHP implementations for SASS.

This is the most important reason. It is not a question of whether LESS or SASS is more powerful, it is a question of what stable PHP implementations were available when a decision had to be made.

The cool bit is the flow-on benefits of having a pre-processor built directly into Magento.

  • By Magento incorporating a CSS pre-processor natively, different phases of the development lifecycle of a site can be supported easily.
    • During development, changes to input files are available immediately. You just edit the .less files and Magento looks after the rest. This is great for developers.
    • In production, Magento pre-compiles the .less files to produce optimized and cacheable static CSS files. The result is fast CSS with no additional effort.
  • Building the pre-processor into Magento means developers do not have to learn how to run LESS (or SASS). You edit the source files and Magento takes care of the rest for you.
  • An advanced site is may completely replace the CSS provided by Magento, making the whole topic irrelevant. You can use SASS to generate the CSS files by hand on a site if desired – there is no lock-in to use the CSS provided with Magento. You just wont get the automatic CSS generation happening in developer mode.
  • The internal Magento framework has been designed to slot in additional pre-processors, so SASS support can be added later if a stable library does become available. Most LESS files are valid SASS files.
  • I would not be surprised if some enterprising community member tried to process the Magento supplied .less files using SASS – then developers could use SASS while still leveraging the Magento supplied responsive theme. (Just don’t ask for support from Magento! 😉


As can be seen, the Magento selection of LESS over SASS was nothing to do with which was a better technology – it was around availability of quality PHP implementations of the pre-processor. Having the pre-processor available inside PHP has enabled Magento to make it easier to use a pre-processor. You edit files and you are done – no special compilation steps required.

The end result is web developers can simplify the management of their CSS files using this technology making it easier to create and manage high quality sites.

Update 6/23/2014: Looking deeper I think there are enough differences between LESS and SASS syntax that I struck out the text around using the LESS files as SASS directly.


  1. timopenstream · · Reply

    Fair enough.

    Just one question. What about minification? Will there be (is) anything additional to LESS merging all CSS into one file? Like wrapping all into a single line, gzipping etc. If let’s say during migration of a project from M1 to M2 I prefer not to convert all stylesheets to LESS but plain CSS by just adding a module related CSS file to `default_headers_block.xml` of corresponding module will it be also minified?

    1. I believe yes, but I will dig to get details.

    2. The LESS pre-processing pipeline does minification of the CSS files. You can also generate a merged CSS file via the LESS engine if you lay your files out correctly. (LESS will effectively #include your files into the big CSS file we generate.) See also //@magento_import “modules.less” which looks for all files with name module.less according to fallback strategy of theme, parent theme, module, and web/lib/css and imports them all.

      Separately, there is a current feature in Admin UI to merge CSS files as well, but we might review this in the light of other changes to see if it is still the right approach. (Opinions welcome!)

      In terms of normal CSS files we are looking at whether to make a minification pre-processor available there as well. (If you rename the files to .less that will happen now (all legal CSS is legal LESS), but I think you want to leave them as .css files and have them minimized. I don’t believe we have that plugged in today.) Minimization is something that (to me) makes more sense changing based on environment. E.g. minimize in production, not during development. So having in a file like default_headers_block.xml does not feel quite right to me. It feels more like a configuration setting you want to have set differently based on dev/test/prod environments wouldn’t it?

      1. Hi, I did for Magento 1.x a minification extension I hope that it will be useless for Magento 2.x 🙂 However regarding the approach for the minifcation of CSS/JS files, I invite to take a look this module from Gordon Lesti, I like its approach: and the related article It may help

      2. Thanks! I will make sure the internal guys know of this.

      3. Matthias Zeis · ·

        > It feels more like a configuration setting you want to have set differently based on dev/test/prod environments wouldn’t it?

        I agree.

      4. timopenstream · ·

        Right. Minification shall depend on configuration setting regardless of the technology used or if stylesheet was added through `default_headers_block.xml` or `module.less` approach.

  2. Hey , i want to start develop a theme for magento with scss compile.
    I see you are involved at the ShowDog repo

    If i’m a developer who want to create a new brand theme .

    Should i use less with grunt as webpack like at the parent time will be blank-theme or should i use magento2-frontools repo ?

    I really need a professional answer if you can because there is a lot of opinions and its very hard to know what is the right way to get started

    Nir Goldman

    1. From the official Magento perspective, the SNOW.DOG work is an experiment powered by the community. If it works and there is sufficient community interest/support, we will merge it into core. There is no commitment that it will be merged in, no commitment of when. There is a “goal” of “around the end of the year” so it does not drag on too long, but that is all.

      The Less files will almost certainly continue to be supported for a long time. If not “supported”, then at least “available”.

      So I think the risk is low basing on Less for the next year or two. That would be my stable response. If you are interested in contributing towards improving the platform, then I would get involved or use the SNOW.DOG work. I see that as the higher risk path, but I am personally very hopeful it will result in a great outcome and the future path for Magento. But until then, I consider it an experiment.

      I hope that helps!

      1. Thank you for your detailed comment!.i take your advice and do it with less files from blank theme and gulp webpack. I also note it that most of the them s in them forest are using blank theme as a parent for the theme the offer for sell

        I will keep to do it with less and gulp for this moment until Sass will be park of the core.

        In general-I get from your comment that is better to trust on the core of magento when I develop modules or themes at magento 2 at this moment because it’s only a 2.1 version and most of my development experience at magento 1 based 90% of core .

        This comment really help me and give me the first step to build a default theme for my projects .


  3. Oh, I may have missed answering a question. The choice of Grunt vs Gulp does not really affect the end result. You ship Less files or CSS – not tools. You can use Less with both Gulp and Grunt during development. I liked the Gulp tools, so that is what I was using. But there is nothing wrong with Grunt either. I liked the SNOW.DOG setup because it got dependencies etc worked out automatically. But there is no a right and wrong answer here. Both work fine.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: