Why is Shopify such a douche towards Frontend Developers?

It all started in November 2020, when one changelog announced the depreciation of the Sass/SCSS in Shopify themes. It all becomes much clearer with a recent statement on their blog that Sass is going out. From the comments up there, you can notice that developers are disappointed. So, what is Sass, and why is Shopify ending its relationship with it?

What is Sass, and why do developers cry about its depreciation?

Sass (stands for Syntactically Awesome Style Sheets) is a CSS pre-processor language. Literally, it’s CSS on steroids. The purpose of it is to expand features of CSS by implementing variables, mixins, functions, loops, and much more. All these features helped in CSS development by reducing the duplication of code.

Sass doesn’t use CSS syntax (no brackets, semicolons, etc.), and it is based on indentation. This caused some Frontend Developers of that time to panic, so the SCSS came out, too. SCSS is the same as Sass, but it is based on the same syntax as CSS. So, when we talk about Sass, we often do think about SCSS, too.

Sass/SCSS has become one of the frontend developers’ most favorite tools. Enabling them to write CSS code like:

.block {
    display: flex;
    align-items: center;
    justify-content: center;
}

.block .element-1 {
    color: #FF0000;
    text-align: center;
    text-transform: uppercase;
    font-weight: 500;
}

.block .element-2 {
    color: #FF0000;
    text-align: left;
    text-transform: uppercase;
    font-weight: 500;
}

.block .element-2.modifier {
    color: #00FF00;
}

Into this (in SCSS syntax):

$color--primary: #FF0000;
$color--secondary: #00FF00;

%element-template {
    color: #FF0000;
    text-align: left;
    text-transform: uppercase;
    font-weight: 500;
}

.block {
    display: flex;
    align-items: center;
    justify-content: center;

    .element-1 {
        @extend %element-template;
    }

    .element-2 {
        @extend %element-template;
        text-align: left;

        &.modifier {
            color: $color--secondary;
        }
    }
}

You can already see some reasons why Frontend Developers love it. Variables are there for them to change all property values in one line of code. You can use the @extend function to duplicate the same properties and then override it in the block where it is called. Nesting is also something that comes in handy, as you can logically separate classes section by section or page by page in the same file. However, why do we even have to keep everything in the same file? There’s also the @import function that helps us to partialize one huge Sass file! How cool is that?!

So, why on a God’s Flat Earth does Shopify want to get rid of Sass/SCSS for good?

Shopify’s Sass is (very) old

Sass is here for 14 years already, and Shopify uses the forked version of Sass 3.2, which came out back in 2012. This version is missing many features that the newer versions of Sass have, including the ability to separate Sass into partials.

One of the main problems partners experience working with Sass on Shopify is that many modern features are unavailable since we are using a legacy version.

Liam Griffin, “Deprecating Sass for Shopify Themes”

While many developers would think that this would be super easily solved with the magic button that upgrades the Sass version on Shopify, the problem is – the magic button can’t be found. In other words, this solution would cause some themes to break, as Sass is not fully backward-compatible.

So what would be the other way to upgrade Sass on Shopify? It’s probably not the best, but having the power of Liquid (Shopify’s template language, if you didn’t know), you could probably have some ability to set the version of Sass being used.

Shopify’s main ditching reason is the speed

As I said in the intro, Sass is a pre-processor language, meaning it compiles into CSS. The compilation process takes time, and according to Shopify – it could take a lot.

The average compile time of Liquid Sass stylesheets in the editor is around 2,000 ms, while it’s only about 300 ms for Liquid CSS stylesheets. 

Liam Griffin, “Deprecating Sass for Shopify Themes”

Now, no need to analyze that – there are two processes included. The first one is converting Sass into CSS. The other one is parsing Liquid tags. As Sass being gone, the only process needed is the one regarding the Liquid tags, which means that the way of getting CSS files is simplified.

The final product of both Sass and no-Sass way is the minified CSS file that your store’s customer will get. The only place where you’ll notice a speed difference is a theme customizer, and that’s actually the speed they are talking about here. But, do we really need to ditch all Sass features for the sake of the speed that only the storeowners and developers will notice?

Shopify does not have alternatives for all Sass features

The reason why Windows is a super successful OS on the market share is the backward compatibility. Many ancient programs are still easy to be set and used in Windows 10 (I’m not saying that you should use those old programs, but you have the opportunity).

So, why is Shopify not ensuring that we still have all Sass features in CSS, even if the Sass is depreciated? There is some stuff that Liquid can take care of, like color filters. There is also some stuff that CSS itself can solve, like variables. But still, not all Sass features are being available in alternative ways.

Let’s take functions as an example. There’s no easy (and logical) way to write down functions only by using CSS and Liquid. The other thing that bothers a lot of developers is the lack of inline media queries. The CSS way of writing media queries means that we should separate our block logic by the screen size, not by sections.

Shopify is not taking the Sass depreciation seriously

The most frustrating part of Shopify’s statement is the uncertain future of old Shopify themes. There’s no a single point on what’s going to happen with Sass-based themes in the future – will they be converted to CSS? Are they going to be deleted? Do we have to convert it? So many questions, yet there’s one answer found in the comment section:

Support for Sass won’t be removed in the short term, and will continue beyond the end of the year, and themes using .scss files will continue to function. New themes may be blocked from using .scss files in the future.

A part of reply from Liam Griffin to one of the concerned developers

Soooo….what does it mean? Is there going to be an if statement somewhere deep in Shopify’s theme compiler that checks for the theme creation date? If so, why don’t we just upgrade the Sass with that same if instead?

The other sign of Shopify’s ridiculous way to satisfy Sass-addicted developers is their recommendation to use Sass-to-CSS compilers to get the pure CSS. But, did they ever put the .scss.liquid file into the compiler? There’s no way the compiler will understand Liquid tags! It’s not that developers are either using Sass or Liquid with CSS – they use Sass with Liquid, too! Unfortunately again, Shopify does not have a solution to this either. It really doesn’t seem that removing Sass is better than upgrading it.

The Conclusion

As a Junior Frontend Developer who works more and more on Shopify’s themes (thank you, pandemics!), I find Shopify’s way of handling issues (that they created) pretty sloppy. It’s almost like cutting a branch that they sit on! They have decided to take a step back in coding experience, so they can improve the performance of the non-essential process for the customers. Instead of providing proper (and better) alternatives for the features they’ll be cutting off, and they just try to justify their illogical reasons.

I wouldn’t be surprised if we get the whole Shopify on PHP one day, just to get a bit more of that performance juice (and I really hope they are not reading this part). On a serious note, I really hope they are going to improve the coding experience as soon as they kick out Sass completely, either by giving us an official Sass-to-CSS compiler (that supports Liquid) or by having all features back through alternative ways.

Subscribe via Email

Enter your email address to subscribe to Tomoweb and receive notifications of new notes by email.

Spread the Word