We just finished a semi-major internal project of upgrading how we handle our preprocessing services for Pens.

Part of that work, ideally the only thing you’ll notice or care about, was upgrading the versions of all the preprocessors we offer the latest versions. We do that fairly regularly, but once in a while, there is a sticking point.

Sticking Points

One of those sticking points was related to Sass. We were on Ruby Sass 3.4.x for quite a while. We wanted to upgrade to 3.5.x, in particular, because 3.4 has issues with some CSS grid syntax and some var() syntax in relationship to color functions. But we couldn’t just up and do it, because CodePen also supports Compass, and Compass is not compatible with Ruby Sass 3.5 (and won’t ever be, Compass is deprecated as far as I know).

We also had interest in moving to Node Sass. Node Sass would mean, hopefully, a faster compile time and moving our Sass processing service to Lambda where we do other Node-based preprocessing.

We found a project that purported to let Compass work with Node Sass. But alas, our testing coverage wasn’t sufficient, and when we went live with this, there were loads of broken Pens. Not only were many Compass Pens broken, but it broke a lot of other Pens as well, notably Pens using hsl() color functions.

So we rolled back to Ruby Sass. But we didn’t want to give up on Sass 3.5, because we know how frustrating the broken stuff in 3.4 is for the CodePen community. So, we decided to get a little clever with it.

The Solution

We now upgrade everybody to Ruby Sass 3.5, unless we detect you’re using Compass. In that case, we process your Pen with Ruby Sass 3.4 (in a process that supports Compass). Everything should be all good now, except for the fact that there were some Compass functions that worked even if you didn’t explicitly @import "compass"; So if that appears to be the case for you, import Compass and you should be all good.

The Future

We don’t really wanna give up on Node Sass, as there are some advantages there for everyone, but as far as I know Node Sass is kinda on lockdown. Specifically, because it’s just a binding for LibSass, which:

Current LibSass 3.4 should be compatible with Sass 3.4. Please refer to the sass compatibility page for a more detailed comparison. But note that there are still a few incomplete edges which we are aware of.

The future here is a bit hard to suss out.

This year-old post by Sass-creator Natalie Weizenbaum has the most important information in it. TL;DR:

  • Ruby Sass will stop being developed on (although 3.5 came out in Ruby Sass 6 months after this).
  • The new official version of Sass will be Dart Sass, but it hasn’t reached a non-beta yet.
  • Node Sass will be able to bind to Dart Sass, so Node Sass will still be super widely used. Possibly easier to make into a web worker?
  • LibSass has last developer power, so might also ultimately be deprecated?

We’ll be staying on top of this the best we can. At the moment, we’re thinking of offering an opt-in choice to newer versions of preprocessors to avoid backward compatibility issues, unless the new version is somehow perfectly backward compatible (which hasn’t been the case so far).