Magento 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 @VasiliySeleznev 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.
LESS and SASS
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! 😉
Conclusions
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.
Alan Kent's Blog 
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?
I believe yes, but I will dig to get details.
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?
Hi, I did for Magento 1.x a minification extension https://github.com/diglin/Diglin_UIOptimization. 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: https://github.com/GordonLesti/Lesti_Merge and the related article http://fishpig.co.uk/blog/why-you-shouldnt-merge-javascript-in-magento.html. It may help
Thanks! I will make sure the internal guys know of this.
> It feels more like a configuration setting you want to have set differently based on dev/test/prod environments wouldn’t it?
I agree.
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.
https://medium.com/@rogerdudler/front-end-technology-stack-survey-2014-809f7a8c92f3 was interesting reading.
Hey , i want to start develop a theme for magento with scss compile.
I see you are involved at the ShowDog repo
https://github.com/SnowdogApps/magento2-frontools/issues/26
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
Thanks,
Nir Goldman
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!
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 .
Thanks
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.
Hi Alan,
Thank you very much for running this blogpost and helping people!
Would you please advise me with these questions below, which were related to Magento Open Source and Commerce Edition 2.2.2:
1. What would be the main benefits of using Grunt tool Vs core Magento client side LESS compilation methods?
2. This question is related on how efficiently handle the LESS compilation process during the code deployment process, when Magento runs in production mode. As it was mentioned on one of your DevBlogs (https://community.magento.com/t5/Magento-DevBlog/Magento-2-2-Deployment-Improvements/ba-p/73119), to minimize the downtime we can perform code compilation and web asset generation steps on a separate server (or folder), before set Magento to maintenance mode:
a. Does the server-side LESS compilation happens as part of the web asset generation step in this case?
b. We are trying to automate the deployment process (by using Webistrano tool). Would it be correct to run the following commands (during deployment), with the below order to cover all theme related changes in this case? Also please advise if I missed any commands here:
magento setup:static-content:deploy
magento dev:source-theme:deploy
magento cache:flush
c. No need to setup a database connection to run these commands above, because these commands will be executed on a separate server (or folder), where only Magento codebase (build release) exist. Would you please confirm if this concept is correct?
Best Regards,
Rustam.
1. Grunt supports incremental compilation – you save a file in a text editor and it recompiles. If you have BrowserSync or LiveReload going, you see the changes in the web browser window in seconds. Using the Magento tools are much slower (they recompile everything and you have to run a command by hand).
2a. Yes, server side less compilation is part of the web asset generation.
2b. There are a few other open source projects around that improve the deployment process that might help.
2c. Recent versions of Magento now are able to pick up all settings for compilation from files on disk, avoiding the database dependency. Older versions needed the database around to work out what themes and locales are supported by the site. You might like to check out my UK Live talk for more details on the new 2.2 features in this area.
For 2b and deployment, you don’t need the source-theme deployment step – it is only for Grunt to use. If you are going to compile using Grunt, then you would do that before the static content deployment step. You also need to do the di-compile command for other files that are compiled for speed (e.g. dependency injection XML files are converted to PHP for speed of execution).
If you have not visited the docs recently, there is a lot more in this area than there used to be. But you might also like to look around at other projects, such as the work David Alger did with Capistrano (http://davidalger.com/development/magento/deploying-magento-2-using-capistrano/) to share effort on existing projects (or learn from them).
I forgot to mention there is a “deployment” group in the Magento Community Engineering slack channel as well. Might be a good place to share ideas with others on the deployment aspects and compilation etc. You can find instructions on how to join the slack in https://community.magento.com/t5/Magento-DevBlog/Community-Engineering-Update-August-2017/ba-p/74220
Hi Alan,
Thank you for all your suggestions and help!
It seems like that using Grunt will be very useful on the following 2 cases below:
– Using in Magento 2 local development machine, like workstation with local instance of Magento 2 and IDE (PhpStorm). As you advised before, the LESS compilation process will be much faster in this case and the CSS source maps will be generated as well.
– Using the Grunt during the deployment process on Dev Magento server. This would be a remote Dev server where usually all QA works needs to be done and Magento runs in developer mode here. The main benefit would be CSS source maps generation, which maybe helpful during QA process.
And I was start thinking about using the Grunt tool during the production deployment process. I have reviewed your shared sources and chatted with other developers regarding on using the Grunt in (Magento 2.2.2) production deployment. I wasn’t able to identify any major benefits of using it during production deployment, unless if I miss anything here. So maybe using core “magento setup:static-content:deploy -f” would be the best option in this case? I would like to confirm this statement with you before summarize this topic.
Best Regards,
Rustam.
All makes sense. One thing to consider is whether you want to develop and test with gulp (or grunt – gulp is a bit faster I think), but go to production with differently generated files. That is why some like using gulp/grunt for production too.
Thanks Alan, that is a good point! Sorry for bring this topic up again, let me provide some details here and ask you a favor to verify them, just to want to make sure that I am on the same page and didn’t miss any important concept here:
For example if we have a new build (release branch) which passed all QA tests in Dev server and ready to deploy on Staging or Production servers. As it was advised on one of your DevBlogs and articles below:
https://community.magento.com/t5/Magento-DevBlog/Magento-2-2-Deployment-Improvements/ba-p/73119
Click to access The%20New%20Magento%202.2%20Deployment%20Capabilities%20%26%20Patterns.pdf
this was an excellent approach to minimize site downtime during the deployment process, as we can perform the code compilation and web asset generation steps on a separate server (or same server, but separate folder), before put Magento into maintenance mode and switch the code. Once these steps will be completed on a separate “place”, then the following tasks can be performed on the production server:
enable maintenance mode
pull or switch code (or symlinks)
magento setup:upgrade –keep-generated (if any DB schema changes)
magento cache:clean
magento cache:flush
disable maintenance mode
So looks like that code compilation and web asset generation steps processes doesn’t impact to the production server downtime here. What would be the benefits of using gulp/grunt in this case?
With 2.2 I think you can go a bit further. There is a cli command to detect if any schematic change, possibly avoiding need to go into maintenance mode at all (for some deployments).
But to your question – the benefit of using gulp/grunt for the production build is only in case there is a difference (e.g. A bug) in the Magento less compiler. You tested the grunt files but go live with different files? It’s always best to test the files you are going to deploy into production. Otherwise you are not really testing what matters most! You production code!
Now I got your point, which was related to testing and deploying compiled files (codes) in 2 different compilers: grunt and Magento less compiler. Also thanks for the cli command hint, I didn’t know that!
If we review the case which have 3 environments (servers) like dev, staging and production, where:
Dev server – Magento runs in developers mode, these 2 Grunt commands were used to deploy static view files: “grunt clean” and “grunt deploy”.
Staging server – Magento runs in production mode, this server closely match with production environment, Magento core PHP less compiler “magento setup:static-content:deploy -f” was used to deploy static view files.
Production server – Magento runs in production mode, Magento core PHP less compiler “magento setup:static-content:deploy -f” was used to deploy static view files.
So in this case, the new build (release candidate branch) release and deployment process would be as following:
1. Deploy on dev server and test;
2. If pass QA then deploy on staging server and test;
3. If pass QA then deploy on production server.
The same Magento PHP less compiler will be used on both (staging & prod) servers. We can test the compiled files (by this compiler) on the staging server, before the same build release will be deployed on production. Would it be safe and best option to use grunt tool on the dev server only in this case?
Thanks for your help!
After analyzed your last comment and compared with different deployment scenarios, I found out that using Grunt/Gulp will be good option in my case. Thanks for your help and guidance!