We know we want to begin using SCSS. There are at least two major reasons, both related to the utility of coding or development work.
First, CSS is redundantly verbose, lacking some niceties that prevent unnecessary typing. All coders hope to avoid repetition; it’s not a matter of laziness but one of elegance and achieving the best product possible. When we look at a technology capable of nested hierarchy, we are more pleased with what we see than if we must type a new line for each element.
Secondly, some features of SCSS make our visual style much easier to maintain. The utility of SCSS is magnified if you consider the concept of theming. Moving forward, I’ve heard it said in meetings that we may want to provide more significant rebranding for our clients. SCSS can help us make our CSS reusable with syntactic features such as variables and mixins.
To say that we have decided on SCSS (or LESS) is momentous, but it is also not really saying much. As a company that is in the middle of converting a legacy codebase to an Object-Oriented, refactored framework, we have to decide on the exact dimensions of the task.
Those dimensions are:
Technology for production Technology for developers Do we pick up from here, or begin retroactive work? How will uniformization interlock with moving ahead?
Technology for production: how should the app handle SCSS? As far as I can see, the major candidates are Grunt, Gulp, WebPack, Robo.php, and PHP SCSS.
This presentation is geared toward SCSS. That can be done in more and less involved ways. The higher-effort ways offer an advantage. Work we do now getting up and running with a task runner will help us later. We may have other tasks we want to automate. Appositely, minification has been mentioned as one such task. Among aiding load speed, minification strips comments from the code.
If we use Gulp, Grunt, or WebPack, everyone may need to get familiar with the technology. There may be some level of effort to getting it running on each dev’s machine. The lower-effort methods may not require individual devs to do anything at all--except begin using SCSS.
Gulp, Grunt, WebPack, Robo.php
No configuration; functional 3k modules Easier than Grunt A little slower than Grunt--but does that matter? Strong community Grunt 6k + modules Faster than Gulp More difficult to configure Robo PHP Seems like a smaller community Works with Composer Staying PHP - Possibly easier to customize and use for a variety of tasks No module count; they definitely exist for the basic tasks http://robo.li/tasks/Assets/ Possible overlap with skinnycli
WebPack Josh will tell us more about WebPack
The alternative to a task runner would be to say let us employ something that focuses on SCSS. We could choose not to worry about the other tasks till it’s necessary. PHP SCSS is the example. With this solution, you place your SCSS in one or more specified locations. There is a PHP script you point to those locations. When you put your SCSS links in the HTML, you point them to a name that includes the PHP script. The files are cached, so if they already have the most recent version, no SCSS compilation is done. Only when there is a change does the next user compile it. There is a way to trigger it manually from the CLI. We might be able to set this up without each individual dev having to do anything. I see this as the only advantage. We can deduce that there is a slight server-side slowdown, probably insignificant.
I tried to write off Robo.php, and almost did. Grunt and Gulp are much more famous and the famous apps have a lot of benefits most of the time. But I’m surprised I haven’t heard so much about Robo. It looks like a really well-done project and it’s integrated tightly with Composer.
Conceivably, with Robo you could set up the site so that Composer just runs the whole deployment as a script. If we are seeking to get a single command-line line, then perhaps we want to go the PHP direction. This might be more difficult to set up.
Technology for devs Even if we implement a task runner, it should be fairly easy for each dev to get up and running.
If we had decided to require only committing CSS, not the precompiled SCSS, then we would be able to say that each dev could choose the technology he liked. In my opinion, we need to commit the precompiled code to get maximum advantage.
A good link for help: https://blog.omgmog.net/post/getting-started-with-using-sass-in-your-existing-website/
Uniformization and Retroactive Work
Getting all of our CSS under the same hierarchy will take a good deal of effort. Much of the effort will be in compiling 129 separate files into a single set of, say, 10 or so). For example, each support tool pretty much has its own CSS file. There will be localized features and namespaces that need to be made universal. Otherwise, changing the global files will not be effective. If we don’t combine all these smaller files, then none of this will do much good.
Also, we have inline styles in legacy code.
For whomever does this, I do believe there may be one or two tools out there that could help. If you think about the task, however, it seems like a good deal of it will defy automation. It may involve deciding which styles give the same results and reducing duplication. Further, the tool would have to be self-hosted. It can’t make ajax calls that might send our site scrapings to other hosts.
SCSS and Mobile-Readiness / Responsive Design Because mobile development is tied up with the subject of SCSS, it might be good to discuss which parts of the application we want to get mobile-ready first. Is it possible that certain CSS attributes will be preferable for our uniformization efforts?
Official SASS documentation: http://sass-lang.com/documentation/file.SASS_REFERENCE.html