Replacing Sass · Discussion #44 · Shopify/polaris · GitHub

We’ve noticed several growing pain points to using Sass at scale. Some of these apply to Polaris and teams using Polaris, while others impact development across Shopify.

In Polaris, the original Sass variables, functions, and mixins are creating a burden with newer technologies that have been introduced: CSS variables and JS utilities. This has led to added overhead in how these technology layers interact. As an example, adding a simple border style in your project would involve using a specific Sass mixin that applies a CSS variable. This CSS variable value and name is generated from our tokens package. This method works but could be simplified to avoid a chain of dependencies.

Sass requires additional configuration to a project’s build process in order to convert Sass files into web-ready CSS. This was a particularly tricky and early bottleneck when writing new tooling for applications and products. In order to reduce the build time performance of compiled Sass files, the Sass provider maintains its own cache for each processed file. There is also a required Sass import fragment addition that is used specifically for Polaris assets. This helper doesn’t scale easily for other build configurations if this pattern were needed elsewhere.

While this strategy for processing and caching Sass improves our build speed in the cloud, it also would be nice if we could avoid this step altogether. There are faster libraries than node-sass for processing styles, solutions that could either reuse existing build-steps or leverage modern builders such as es-build.

Library consumers are using private functions and mixins intended for use within Polaris. Though marked as private, these utilities aren’t strictly protected. This makes it difficult to maintain and update Polaris; we can’t be certain how these private APIs affect users. This has caused large issues and breaking changes for our merchant experience in the past.

Next steps

The Polaris team is exploring alternatives to Sass that better serve our current needs from CSS. Stay tuned for a follow up on our explorations and learning.

In the meantime, we want to know your thoughts on removing Sass! Join the conversation in the comments below..