Treehouse & Sass: Past, Present, Future.
If you’ve ever written your stylesheets with Sass, you know how much of a Godsend it can be. We get access to lots of really helpful features that make our stylesheets more readable and powerful. But with power can also come problems. With Sass being a preprocessor, it means we are one layer removed from our actual stylesheets. With that in mind, this post is a confession of how Treehouse has written Sass over the years: for the good and the bad. Since we’re always trying to iterate and improve upon what we have, where we’re at right now won’t be where we are in the future.
The Past
The front-end code for Treehouse is complex, ever-growing, and as time goes on becomes trickier to manage. This is likely true for anyone who’s worked in a larger application over a long period of time. The two reactions to a messy codebase are typically: blow it up and start over again or gradually improve over time. The first option can be tempting but requires a large amount of dedicated work and resources (which isn’t always feasible). It often risks changes to the UI for the sake of code cleanliness (which isn’t great for the end-user). Our team chooses to iterate and improve and we’ve had to overcome quite a bit of code debt over two and a half years on the team.
Some of the front-end problems we’ve faced were inconsistent naming conventions when writing classes, which led to confusion and headaches every single time you pulled down a part of the codebase that you hadn’t touched. There was a time you could look at our stylesheets and find a class on one page that nested everything under a single ID, one that chained similar classes together to override global styles, or another that followed the structure of the HTML with nesting in Sass. We saved stylesheets and wrote styles in various places, which led to duplication in components, pages or patterns. We’d often end up doing the same work twice with slightly different permutations and not even know it. When I first got hired at Treehouse, I can remember looking into stylesheets and finding the same classes written in multiple sheets, all overriding each other in different ways. It was sometimes necessary to edit 3 stylesheets just to get the changes you wanted to a single element on a page.
We write all of our stylesheets in Sass. But not everyone on the team has as much experience with Sass as others so we’d end up making small mistakes that led to style duplication and bloat in our compiled CSS. At one point our styles were so out of control that if you wanted to make a change to a stylesheet that was being imported in multiple partials, you’d have to wait upwards of a minute for it to finish compiling and the page to refresh. It was pretty painful wasting so much time waiting. We eventually dug into it and realized a couple of mixins we’d written were creating an enormous amount of code and compiling 100s of lines of duplicate selectors. These sort of issues can be hard to track down when you aren’t always looking at the compiled CSS that your Sass is creating.
The Present
As our team grew, efficiency became a priority. We started working on small improvements that would have big impacts in our efficiency while writing front-end code. The first thing we started to do was improve our documentation. We’re still in the process of this, but we’ve made big strides to create a style guide that documents all the main components and patterns we use throughout the application. Not every page in the style guide is completed yet but we’ve got the bones there to make it easier for us to add to as we go. We’ve been pushing pretty hard to make sure that every person adding new components takes the time to document the important aspects of it. This can be pretty easy to miss when you are moving through features at blazing speeds and is something we’re still working to improve upon as a team.
We’re employing a modified BEM approach to our class naming scheme in order to get all the designers on the same page when we go about adding new classes for the projects we’re working on. I won’t go into a BEM lesson here, that’s not the point of this post. But I will say that it is very important to make sure you have some sort of methodology or reasoning behind how your team names elements, it can save a lot of time and frustration.
We also started making a concerted effort to place styles for pages, components and patterns in directories that made the most sense for our app. For example, if a designer is working on styles for a navigation element that we can use throughout the app, they’d save the stylesheet under /global/_navigation. If they were making some custom styles that would only live on a certain page of the app and not effect anything else, they’d save the sheet under /views/[view-name]. This helped us keep things organized and as separate or inclusive as we needed. The same pattern goes for layout styles, mixins, etc. We just make sure the place we’re saving it matches up to where it will be used.
We’ve really wanted to switch to Libsass for a while now. This would get us away from the slow beast that is rails-sass and move us to compiling Sass with C. We made this switch a few months ago and now our global style changes compile in seconds, saving us hours in a month across the entire team.
The Future
We’re pretty happy with where we are now compared to a few years ago, but still have a long way to go before we’d consider our frontend codebase something to be really proud of. We are still facing a few pain points that we’ll be working hard to overcome over the rest of this year. We lack a completed style guide or pattern library (which we’re slowly working to complete). We would like to find some sort of Sass linter that would help us enforce class naming styles and conventions with an automated process. Our designers will be taught more about Sass so that everyone touching stylesheets has a clear understanding of all the tools and best practices. Employing more of a defined front-end code review process will help us get better at writing code that looks like a single person wrote it, leading to a healthier and more understandable codebase. Our developers are really thorough when it comes to backend code reviews. Designers tend to make sure something looks or functions right but don’t necessarily dig into how the code smells or how we could refactor things using Sass.
As I said in the beginning of this post: We’re always looking for ways to iterate on process, documentation, and front-end solutions with an eye towards making us better and more efficient. We’d love to hear about how your team has solved any of the front-end woes you’ve faced or if you’ve felt some of the same pain points we have.
Chris is a Product Designer on the Engineering team at Treehouse. We’re on a mission to design, build, and maintain the best online learning service in the world. Sound awesome? Join us!
If you enjoyed this post, please tap or click the ♡ to help us promote it others. For more posts like this one, be sure to follow the Treehouse Engineering publication. 👋
