What! After all these endless debates Magento 2 might move from Less to Sass?!
One of the original reasons for selecting Less over Sass was at the time there was no PHP implementation of a Sass preprocessor. There was also no clear winner between Less and Sass in the market. While this may spark a debate, from all the feedback we have received Sass is pretty clearly winning.
How Different is Less and Sass?
From a technical perspective, not a lot really. There is a lot of commonality between the power of both preprocessing languages. So frankly if you have spent lots of effort learning Less, it won’t take you long to move to Sass.
The decision to move is not a question of expressive power, it is a question of market mindshare. There is extensive feedback from the community that Sass is the better way to go.
So What is the Work?
What is the work required to do the move? There are several aspects:
- We need to port the Magento UI Library, blank and Luma themes, admin theme, and Less files in core modules from Less to Sass. The core library is the “real” work here.
- We need to give extension developers enough notice so that if they are using Less they have time to migrate over to Sass. We want to make the new Sass files available well in advance so porting can be more easily scheduled. We also want sufficient time for feedback if any improvements are needed.
- We want to give the frontend developer community enough time to think through issues to make sure we get the new files “right” (or as right as possible), before they become official. I am sure frontend developers always agree, so I am not expecting any challenges here… ummm.
It is worth remembering that there are distinct communities interested in these files:
- Magento development has to maintain and build them into the core product.
- Solution Partners need to build rich, seamless solutions for customers, worrying about performance and maintenance.
- Extension Developers need to build extensions that are easy for Solution Partners to work with.
- Theme Developers need to be able to change the theme of a site with minimal effort.
Oh, and to be clear, this work is not about changing the look and feel. This is not a UX redesign. It is achieving the same look and feel using Sass instead of Less.
How is this Going to Happen?
SNOW.DOG have already ported the blank theme from Less to Sass. They also did some great work with Gulp integration with Magento 2. So Magento has asked SNOW.DOG to lead a community effort around the Sass port, which SNOW.DOG has graciously agreed to do.
The idea is to develop the new Sass files as a community project, get feedback from multiple interested parties, and then merge into Magento 2 at a future date. The benefits are:
- Get real world frontend developers working through issues and complexities in the open.
- Accelerate development – the core Magento team have many other obligations as well. This is a way to get the move done sooner.
- Tap into the great talent pool and real-world experience in the community, while Magento remains involved for consistency.
- See how well larger scale community-led projects work in practice.
Are the Less Files Going Away?
Maybe one day, but they will probably sit around in the product (or in a separate module) without being actively maintained. As above, Magento can still support Less, so all the existing files will continue to work, it just won’t be the recommended default. At the end of the day, the output is CSS.
What is the Architectural Changes Behind This?
This is still to be decided, but the current plan is around simplification. Sass might be out of date next year given the rate of change in frontend development. So what is stable? The current plan is to base the solution around:
- Files on disk – with modules and themes being able to override existing files. This is how a theme can customize. No other magic, just file replacement using the standard Magento file fallback strategies.
- External tools can convert source files to CSS. We need to think about what to build into the product, but it must be possible to run external tools (like Grunt and Gulp) in the build process.
- Magento tools for merging CSS files (maybe). Basically we want it simple for small sites to get reasonable performance. So we are considering a default mode where modules can add new CSS files if they want them, and Magento will merge (and minify) them into a single file with a single setting in the Admin panel. Expert frontend developers may turn this off, and do all file merging by hand for fine tuning.
Assuming the project is successful and consensus is reached of the best way to leverage Sass, the objective is to get the final files merged in by the end of 2016. This would include an extended period of time for extension developers to be able to move any code they have (if they just used raw CSS there is nothing for them to do). Note that this is not a guarantee, but it is a goal. The more important aspect is to get the Sass files right, where Solution Partners, Extension Developers, and Magento are all happy with the new files. This is more important than a date.
OMG – The Sky will Fall! Can’t Magento Make up their Minds?
I would rather fix problems. We don’t want Magento to be unstable, but the consistent feedback is this one is worth changing. And if the frontend community comes back and says “don’t change anything, Less is great after all” then we won’t! We will let those in the community who care most get involved in setting the future direction here.
And I think the breadth of the community involvement is the greatest protection that the new Sass files, when completed, will be a step forwards.
And the move is really to abstract the Magento support for CSS preprocessors. We want to have less built in dependence on a particular language, and instead make it easier for a project to select their own. The core files are really a great place that Solution Partners, Extension Developers, and Theme Developers can all meet.
I am also not expecting significant impact on extension developers as: if they use their own native CSS files there is no impact; if they depend on our Magento UI Library Less files, they can continue to generate CSS from them (although this is unlikely to be widespread due to a current defect making it hard for modules to use our Less libraries). The biggest impact appears to be on solution partners (the primary source of the change request, including using more standard frontend developer tools) and theme developers. But please leave a comment if you have data indicating otherwise!
Thank you to Kuba and SNOW.DOG for offering to oversee this project. SNOW.DOG has already looped in a number of people from different Magento development shops to get the breadth of perspectives that come from such a diverse community. Staff from Magento are also involved, but this is going to be a true community project. Hopefully, this will serve as a great template for further work in the future, drawing upon community expertise to get a product built that best addresses the community’s needs.