modxcms
Proposal: Remove Sass from theme build
Proposal
Summary
I propose removing Sass from the theme build pipeline and refactoring it into CSS.
Why is it needed?
Currently, the theme is built using Sass, which makes it difficult to maintain and hard to selective adjust. Additionally, the changes in Sass 2 will require a significant refactor of the build process.
Suggested solution(s)
I propose refactoring the files to CSS with a postCSS (or similar) build pipeline. Additionally, I recommend leveraging CSS var() properties to make it significantly easier to modify colors and attributes.
I'm so very in favor of this. It'd be great to have a Manager theme consisting solely by adjusting the CSS variables. (Also, light/dark mode would be killer, too.)
I'm totally in favour of removing Sass as well. I'd like to learn more about how the postCSS would work for indididual contributors having not used it recently.
This issue has been mentioned on MODX Community. There might be relevant details there:
https://community.modx.com/t/input-wanted-from-modx-contributors-re-css-in-the-manager/8534/1
I sometimes like using Sass in my own work, but I can see where it might be a problem for team-based projects with lots of players. +1 though I think it's likely to trash some advice in my older blogs about customizing the MODX Manager ;)
Currently, the theme is built using Sass, which makes it difficult to maintain and hard to selective adjust.
What's difficult about Sass? 🤔 There's definitely something to say about modernising the pipeline we have today as it's been a number of years and there may be complexities and outdated dependencies we don't need, but why we hatin' on Sass specifically. 😂
Additionally, I recommend leveraging CSS var() properties to make it significantly easier to modify colors and attributes.
Sass and CSS var() properties are not mutually exclusive, tho that may depend on specific versions as they have similar overlapping syntax that has changed in different versions.
Most comments so far do not seem to address the specific proposal rather just expressing wishes that can be accomplished with most, if not all, pipelines we can imagine.
Absolutely support removing sass and using var() instead. Cleaner builds and modern CSS now has support for most of the reasons we would use sass anyway.
@Mark-H
What's difficult about Sass?
This is mostly personal experience, but I've been working with modernizing some projects that were built using Sass. We used to use it on many old sites and projects. The Dart Sass team is actively moving to a new 2.x release, and frequently introducing breaking changes / deprecations. I'm finding that when I revisit a project from a year or so ago, I have to first refactor a significant amount of Sass if I want to update the build process.
While var() and removing sass aren't mutually exclusive, I feel like the refactor process would benefit from going to a more stable build process.
Sass is a great tool, but the dependencies are getting a bit long in the tooth and the aforementioned version 2 will be as much work, possibly more, as I understand it than using native CSS features. CSS variables along with native CSS nesting and calc() functions solve a ton of problems that used to be only possible using Sass.
@matdave mentioned PostCSS; here's a quick intro article for those that aren't familiar with it. https://www.seancdavis.com/posts/getting-started-with-postcss/
I wonder if there is anything we couldn't do with modern CSS features that we're currently doing for the Manager theme's Sass build method?
Could this break custom manager pages/3PCs?
Guys - So we already use postcss for some elements of the 3.x build. 2.x is still way, way in the past, and is going to stay there AFAIK.
That aside, I have a different perspective I think we should consider: While I'm all for more modernization, I feel like efforts would be much better utilized knocking down the pretty significant Issues list and, more importantly, helping with envisioning a much-needed total rebuild of MODX — moving away from ExtJS and toward a new front end platform for the manager. With that is a desire to move to a headless architecture as well.
A non-ExtJS version is absolutely in the future, but we need solid, current tooling for 3.x in the interim; 2.x is only getting bugfix and security updates now and wouldn’t be in scope for this.
The effort to convert to modern CSS is not remotely in the same ballpark as purging Ext, or likely even moving to the future Sass 2.0 with its breaking changes and additional dependencies. The benefits of adopting native CSS features could make for easier ongoing maintenance updates and might help attract contributors that don’t want to mess with Sass that’s a bit long in the tooth.
My only hesitation is if it somehow breaks some Extras Custom Manger Pages. But if we aim for CSS that provides the same results as tbe current Sass-generated implementation, it should be a non-issue. And I suspect we may wind up with less overridden CSS and better performance, too.
Gotcha, gotcha. Thanks for clarifying y'all. I can appreciate getting ahead of maintenance getting increasingly complex. Clearly a bunch of people feel strongly about this so... good luck and have fun ;)
My only hesitation is if it somehow breaks some Extras Custom Manger Pages. But if we aim for CSS that provides the same results as tbe current Sass-generated implementation, it should be a non-issue.
Yeah, as long as the final CSS covers the same structural elements, which logically it has to in order to style the core views, CMPs should be fine too. There'll always be some edge cases but those don't have to be a problem, and just involving different extras in testing the updated theme should surface those.
While I'm all for more modernization, I feel like efforts would be much better utilized knocking down the pretty significant Issues list and, more importantly, helping with envisioning a much-needed total rebuild of MODX — moving away from ExtJS and toward a new front end platform for the manager. With that is a desire to move to a headless architecture as well.
I can appreciate this argument, and everyone only has so many hours in their day.... however, until there is a written out plan for that wishlist and some effort to coordinate work on that, halting any other progress is a great way to get stuck in a stalemate. We should keep iterating until we figure out how to approach that dot on the horizon.
And I suspect we may wind up with less overridden CSS and better performance, too.
Seriously doubt any amount of CSS optimisation will be noticable in an ExtJS 3 driven app. Even if you deleted all of the CSS. 😆
To be clear, I'm not being critical of the idea. I'm was just raising a question about priorities.
The total rebuild is certainly the reach for the summit—not something to stop other progress on account of. It's just there's also that nagging 600+ issues hanging around (I realize many are not bugs and not 3.x-relevant). I'll get off the soapbox now ;-)
I didn't take it as critical by any means, just a healthy discussion. The 600+ issues is another topic with another proposal that's overdue, too. I suspect many are actually no longer relevant or fixed with the 3.x release and bug and security fixes that have been done over he years. More on that in the forums, soon.