It’s a truly remarkable time to be a front-end developer right now. I’ve gone on in previous blog posts about advancing technologies providing us with exciting new capabilities. I’ve remarked and commented on the multitude of innovative ideas that really take our front-end potential to a new extreme. However, in light of that, something that can often get overlooked when being wowed by fancy effects, is the oft-practiced. You do it everyday, tens, if not hundreds, of times. These activities have become so ingrained in our day to day that inefficiencies skate by unnoticed.
The Tools I Use
Here at Demac, SASS is a tool that we lean heavily on. It may be old hat to most front-end developers out there but adopting it in different capacities can throw you a few curveballs. When I first started using SASS, it was pretty straightforward. Taking advantage of tools like nesting and variables was easy to integrate into my pre-existing CSS workflow. When I came to Demac, the dynamic changed quite substantially. With a host of other developers working on files and a proprietary framework that I was unfamiliar with, things got a bit more complex. This led me to figure out a way to enhance my workflow to make it easier to integrate new people, and speed up our existing dev’s processes.
What is SASS?
SASS is made up of a number of .scss files referred to as partials. One global file points to all the partials your project requires. When the project is compiled, a single browser readable CSS document is compiled based on your collection of partials. Now, this is pretty awesome already considering power of SASS, but let’s skip ahead a little bit. It’s a couple weeks later and you need to go back and make some modifications to some existing styling in your code. Modern browsers make it easy to see what properties are applied to any given element on a page. They’ll even show you where in the CSS those styles are coming from. But what good will that do us when we’re not directly editing the CSS? We need to know where those styles came from in the partials. Enter source maps. Consider the following:
$ sass --watch path/to/your/scss/input.scss:path/to/your/css/output.css --sourcemap
This will give you your output.css file, along with output.css.map. You can enable source maps in any modern browser.
Once enabled, when you load a website and inspect an element on a page, you’ll see that the browser is now showing you the specific SASS partial the styles in question come from as well as the line number for easy tracking.
Pretty awesome, right?
It gets better. Using SASS, a major feature is the ability to create variables that you can use throughout your partials. While having a lot of different applications, a big one is for your colour palette. Variables can make it easier to draw on a specific hex value without having to actually remember the hex value. Again though, trying to track these things down can be a lost cause unless you’re familiar with the project from it’s inception. By Cmd+clicking on the CSS property itself, if the value was created by a resource outside of the partial where the element was declared, your browser’s Sources panel will reveal the file that the variable was declared in.
Does it get better? Of course it does! I’ll cover a couple things from here, but the hinge pin of my entire workflow is sourcemaps. Without them, I’d wind up digging through dozens of partials trying to find the one I need.
Livereload is a technology that will cut out a huge chunk of your development time, simply by letting you avoid the need to reload your your web page every time you make a CSS change. Pairing a Livereload watcher with a browser extension will allow your browser to refresh ONLY the CSS when it gets updated (like after a successful SASS compile!), automatically updating your new styles on the page without needing the hit refresh and going through the process of getting the server to reconstruct your entire page. This is especially important when working locally in your development environment as the tools like Full Page Cache that decrease page load time are avoided for debugging and development purposes.
Want one more for the road?
Sure thing. This is one I use on and off. The integration into my workflow isn’t perfect yet, but it’s still pretty handy. As of writing this, I’ve only tried this out in Chrome, but I was able to successfully turn Chrome into a full featured Integrated Development Environment, or IDE. In the sources panel, you can add local projects to workspaces in the Chrome DevTools. You can then map these to a network resource, thereby allowing you to actually edit your local files in the Chrome DevTools Sources panel. This is particularly handy when working with SASS sourcemaps as it eliminates the need to jump around between applications to do your development and your testing. It’s all in one place! For a more in depth walkthrough on Workspaces in Chrome, check it out by clicking here.
What’s your workflow? Let me know in the comments.