Migrating From Sprockets to SASS Directives Solved All of My Problems
By: Chris Sigg

The title is obviously a slight exaggeration, but it did result in significant improvements and optimizations to a bunch of RSpec and Cucumber tests that I was maintaining.

  • Faster RSpec and Cucumber test suite execution
  • Simpler style debugging within the browser console
  • The removal of redundant @import statements across the entire inventory of stylesheets
  • Faster site load times


What’s the Difference?

The traditional method of processing and concatenating files into the CSS manifest using Sprockets results in each file being evaluated and compiled independently from all of the other files.  File B has no knowledge of File A and as a result any code that is shared between the two files must be imported into each one individually.  In an effort to DRY up our stylesheets, we’ve condensed variables, shared components, and mixins into several files.  Using Sprockets necessitated that each shared file be imported into every stylesheet.  The redundant code that results from using these repetitive import statements is duplicated within the final stylesheet resulting in a needlessly bloated file.

Files being imported using SASS are evaluated within the namespace of code included or imported above them.  File A has knowledge of all of the shared components and variables declared within File B.  It no longer becomes necessary to import the shared code into each file individually.  It’s that simple and the improvements and optimizations are worth it.

Making this switch resolved a significant issue that was costing us dev time and server resources -

Our RSpec test suite had been growing larger and more comprehensive as we moved to implement Continuous Integration.  An odd bug had emerged where the test suite would occasionally hang for several minutes when executed on local dev machines.  RSPec will compile the assets of the application when rendering the application layout if the test suite is configured to render views.  Compiling the assets was sometimes taking as long as 4 minutes!  This process was reduced to seconds after migrating from Sprockets directives to SASS import statements.  More importantly, the CI servers (which re-compile the assets every time the tests are executed) were finishing the test suite faster and able to merge code more frequently.

  • No more RSpec hangs
  • No more Cucumber fails
  • Travis time reduced from 22 minutes to 15 minutes
  • No dev time waiting for the test assets to compile

It was nearly impossible to disable style within the browser developer tool - 

When debugging style and positioning issues within the browser console, I’ll often start by disabling style attributes before I start creating overrides.  When the attribute is repeated throughout the stylesheet (a result of using the old Sprockets directives), it becomes nearly impossible to disable all of the declarations.  Even more, the console readout can become so large that even parsing an element’s style can require scrolling through several pages of redundant declarations.  This made finding individual declarations nearly impossible.  Migrating to SASS @import statements has made styling our pages much easier as the browser’s developer console now displays only the relevant declarations without repetitive statements.

  • Repetitive imports meant disabling an attribute required disabling dozens of style declarations
  • Finding one style declaration within a sea of repetitive declarations was tedious and difficult

The size of the asset being delivered to the client was reduced -

Smaller assets mean faster load times, which is especially important for mobile users.  Reducing the redundant code within the pre-compiled assets makes for a smaller compiled stylesheet and a quicker load time for the client.  In striving to produce a more consistent experience across the site, we’ve begun to rely more heavily on a catalog of shareable components.  Every additional component was being imported across all of the stylesheets, resulting in exponential growth in the final compiled file.

  • Simple additions to shared files result in exponential growth of the final file

Don’t take my word for it - 

The Ruby on Rails Guide and SASS documentation both recommend the following practice within their respective documentation.  Making the change may require some finessing of the load order, but was fairly easy to implement. Don’t forget to clear your assets after making changes when verifying the functionality of the switch.  Faster test execution, improved load times, and easier debugging make this switch well worth the time.


Meet Chris:
Chris is a Software Engineer at WeddingWire. Chris was raised in Honolulu, HI, studied Computer Science at Georgia Tech, and Horticultural Science at Colorado State University. When he’s not building Rails applications, Chris enjoys working on his sailboat in Annapolis and snowboarding anywhere there’s fresh powder.