Replacing Sass at Shopify

Oh yes, the sound of those Breakmaster Cylinder beats means it is time once again for JS Party. I am Jerod, your internet friend, and I’m joined by my internet friend - it’s Divya. What’s up, Divya?

Hey-hey! How’s it going?

It’s going quite well. How are you?

Pretty good. Good to be back.

Great to have you back. We have a couple of special guests today from Shopify. We have an excellent conversation around open research, alternatives to Sass, CSS, all sorts of goodies. We have Alex and Sam. Guys, welcome to JS Party.

Thank you so much for having us. It’s really great to be here. Really excited to dive into those topics as well. I feel like it’s not just about us; this can benefit lots of companies and communities and things… So yeah, it’s nice to be here. Thanks.

Yeah, I’ll second that. Thanks.

You bet. Well, let’s start by getting to know you two a little bit, and your roles at Shopify. Now, I know you work on the Polaris team, and there’s a design system involved… And I’ll give a little bit of the back-story on how I’ve found this and what I think is cool about it, not just replacing Sass; we’re not here to diss on that… But just the open research, and the fact that tooling changes, need changes, and we can all kind of learn these things together, and take findings from different people’s experiences. Let’s start with you, Sam - what’s your role at Shopify, and how involved are you in this Sass replacement project?

[04:06] Yeah, hi. So I’m Sam, I am a senior frontend developer at Shopify, working on the Polaris team. We’ve kicked off this research looking to find the next evolution for Polaris, and just kind of thinking this to be an opportunity to see what else is out there. We’ve kind of seen these challenges with Sass, but this was a good pivot point for us to kind of take a step back and look at these other alternatives.

Very good. Alex, tell us about Polaris, what it is inside of Shopify.

Yeah, totally. So - yeah, thanks; my name is Alex. I’m a frontend engineering manager at Shopify. I spend most of my time working on the Polaris design system. Polaris - the way that we describe it right now is sort of our North Star. It’s where we head to, what we wanna focus on for design quality across our different experiences. It’s very focused on our admin product. The admin product with Shopify is - if you’re creating a store, you obviously will get orders that come in, and you’ll see them in a big list, or you’ll be managing products that you also see in a big list… When you click on a product you see a form… All of these little parts of the UI are reusable pieces that we put into our design system Polaris.

When a team creates a text input, or a text field, or [unintelligible 00:05:20.03] or a navigation, we have all of these little pieces that we’ve constructed, with strong opinions on design, and that we’ve sort of centralized in one place. We’ll talk a little bit about the evolution of this, because I think that focus on this one admin product also causes pain… But we can get into that in a bit. But yeah, I’m very excited to talk design systems and our research today.

Yeah. Well, what I think is cool about this - not the research itself, although that’s cool as well… But what really interest me is that I had access to this research and these findings, and that’s because you’ve done it all in the open on your GitHub – not Issues, although I always cal it GitHub Issues… But GitHub Discussions on the Polaris repo, inside of the Shopify org. So this was something that floated around, and people shared it, and it came across my radar somehow… And I’ve gotta read and come along for the ride and see what you guys did, and decided on, and all of that stuff.

So I just think this is a really cool trend, and I’m wondering whose idea this was. Is this how you always work? It’s just - hey, put your stuff out there and just kind of learn in public.

Maybe I’ll start, but I want to hand over to Sam for a few things… Our team is really focused, and I think before I even joined Shopify I was really focused on building an open source community… So if you look at the Polaris React repo today, and Shopify’s Polaris website, polaris.shopify.com, we’ve always embraced open source as a platform. We get so many benefits from that, where we have third-party developers who are building applications or products for the Shopify ecosystem, that can use the tools that we’re building and learn from them…

Where we’re at today is “How do we make these tools better for the teams internally at Shopify and better for the teams externally?” And as we go through this process, we wanna work in the open, and we wanna work in the open for many different reasons. The things that come to my mind are strong visions for what we have, but then we wanna hear other people’s opinions. We currently have some opinions now on what we think we wanna replace Sass with, but we don’t just wanna replace Sass and have an internal conversation with just our team. We’d love to know other people’s points or perspectives, and opening up these conversations have really helped us start some of these learning opportunities with other teams.

More recently we’ve had a chat with the Spotify design system team around this, and sort of learning their ins and outs of how they’re thinking about design systems and how they’re thinking about scaling these things… I’ve just been able to put that research in a public place and share that with them. I think it’s a great way for us to just say, like, “It’s there. We don’t have to have a shared Google document with just their team.” We can share it with them, and maybe they’ll have a meeting with another team, like the Atlassian Design System team and they can say “Hey, did you see what Shopify’s working on?” That’s why we have to constantly update links, and everything like that. It’s just all in an open place.

[08:20] But Sam, I know there’s some other things we were think about when we made that open source. Did you wanna talk about those as well?

Sure. Again, coming back to just working in the open was a strong focus we wanted to have for this next part of Polaris. We say in Shopify defaults – we wanna be very transparent internally, and so if we knew that we wanted to be transparent or have this available, ultimately public, why not start earlier? Still having a big release is nice; we will have a good, solid release of whatever we do come up with… But getting that feedback early on I think is really high-value, super-informative to get not only internal Shopify perspectives… And we only know what we know on the team internally, but hearing from experience and the expertise of others outside of Shopify is jsut tremendously valuable.

I think some of the things that have already happened from this open source research, in a way - we’ve had connections with the Vanilla Extract team. We’ve had a meeting with them recently, and I don’t know if that would have happened if our research wasn’t public. We’ve also helped put a spotlight on the Vanilla Extract product. This is how Shopify is investing in exploring, and then putting that spotlight on that product to help other people also get excited about it and want to use or experiment or learn about it, and maybe they’ll share learnings back with us.

The other really awesome thing that I just didn’t realize would happen is we’ve had so many people just jump into those research documents and be like “This is wrong.” And I love being wrong, because it just helps us learn, and it helps us learn that maybe our understanding of this thing was incorrect; our understanding of this tool could have been wrong, and with this plugin or with this thing in the ecosystem we could have made a much better adjustment or solution.

So it’s just great to open source it, see other people’s opinions, learn from other people… WE know what we know, and I think opening that up to the open source community helps us learn the gaps that we don’t know as well. So that’s been a really great experience, just exposing our research and being vulnerable as well. I think that’s the easiest way to describe it - this is our understanding, we’re gonna chuck it out there, and if people disagree with it, that’s great, because we’ll learn from that and we’ll make a better product from that, for our users and for our teams at Shopify as well.

That’s awesome. I think it’s really cool that you’re including a lot of people in the process and decision-making, because it allows you to widen and broaden your own search and your own collection of knowledge… But where do you draw the line with regards to – because there’s always this phenomenon, just like too many cooks in the kitchen, making decisions… So where’s that balance that your team makes with regards to filtering feedback and then making decisions yourself?

I think at the end of the day our team needs to make a decision and try something. We’ll appreciate all the feedback that we’ll hear… We’ve heard some great feedback about Tailwind, or we’ve heard some great feedback about Emotion. It doesn’t mean that we’re just gonna stop doing what we’re doing and go and use those other libraries; we still have to have an opinion and try something and give it a go… But it’s really great, because we’re sort of in a really safe environment right now that if we were to fail with a technology, it’s not the end of the day. We’re still early-day-prototyping and learning… So it’s great to hear those insights, because maybe we’ll go back to those tools and go “Maybe this would be useful with this plugin, or this other approach to using it that we didn’t think about previously.” Being more honest as well… Polaris React, our other open source repository - we have so many issues and so many features that people are constantly asking us to do, or constantly asking us to fix… And we don’t really have an open roadmap right now or an open way that we’re sort of approaching fixing those.

[12:04] We’ve been putting a lot of encouragement back into the people in our community to create pull requests, and we’ll review them and work with you to ship these features… But for much bigger things in that ecosystem it’s really hard to change, because there are so many layers internally as a company that we’ve sort of built into these opinions that we’ve shared that it becomes really difficult to say “If you wanted this in a navigation, we actually have a really strong opinion that that shouldn’t be in a navigation in our internal products.” We can see how that would be valuable in the application that you’re building. That becomes a really interesting tension, and I don’t think we have a great answer for that right now, to just be honest; I think we’re still figuring that out, like “How do we build the best product for our teams internally, as a company, so that we can keep scaling and solving the problems that we need to solve, but also empower the teams externally to build the best applications that they [unintelligible 00:12:54.22]?” Because we would love this system to help not just our teams, but their teams as well.

I do think it’s interesting – you mentioned too many cooks in the kitchen, and just receiving all this feedback, and how are we able to take the bits and pieces that maybe are applicable, and then others that might not be… Some of the feedback I even saw and some of the early discussions on the alternatives to Sass - it made me think about, like, not everyone has the same context our team does, and we’re not able to communicate all o four needs in great detail… It really does provide though a different perspective of what someone else might have, from a different lens, and giving a different context or a different situations.

So there are just like some comments, and it’s interesting to see one person mention something, and then because there is this community involvement, you’re not the one who is on the hook to respond or… You just kind of wait on it, and sit on it, let the feedback simmer, and it’s just good information to have, and you actually see the conversation evolve and people continue to add new perspectives.

I guess I never considered that, that if it’s out in the open, as a community sort of initiative that is led by Shopify, you could let the community continue a conversation, without necessarily being the arbiter of decision-making in there. You’re like, “We’re making this decision, and it’s open to interpretation” and then you kind of let people duke it out and then you filter the feedback… That’s actually really interesting.

It’s always like a form of research. We know what we’ve learned, and now we’ve just opened up for that platform to say “Do you agree? Do you disagree? Do you wanna have a 50-comment thread discussion around Tailwind’s theming abilities? If you do, that’s awesome, and we’ll read that anyway, because we’re interested in that, and we wanna learn more.” But we don’t have to invest ourselves 100% into those discussions. What we wanna invest ourselves into is “Are we making the right decisions for our company and for our external users?” That allows us to stay a little bit more focused, I would say.

I would just add - as we kicked off that discussion, we can continue to make progress and experiment and do our own investigations, and just the feedback that comes in later on is additional information that helps inform our progress moving forward. So if we do reach either other roadblocks or see other opportunities, that conversation that continues to evolve just kind of helps inform that.

So a lot of these discussions tend to be led from your side of things, like “Oh, we’re thinking about replacing Sass”, but is there also an opportunity for the external users, or – I guess I’ll talk about external users, because internally it’s actually easy to raise feedback. But externally, is there like an RFC kind of a process, where users are like “Hey, we’re using this particular tool, Polaris, and we want this being added”? Is there that process, or how exactly do they go about doing that?

[15:45] It’s a lot lighter on the process side right now. We don’t really see Polaris being as complex as something like React, where it’s like “This needs to always be backwards-compatible”, and it has this gigantic community behind it… So it’s a lot more lighter. I would say that our current process is open an issue or a pull request and we’ll have a conversation with you. We have recently started having discussions. We wanted to start a discussion around the approach that we were taking; we’d love to talk with them… But I think that’s honestly a sign that we’ve got a lot of room to learn, and adapting as well… It’s like, “How do we engage these external teams, or agencies that are building things with Polaris, understand their problems and address them in the system?”

We’ve heard great feedback from people that they don’t wanna use React, and Polaris is a very React-based design system right now. Either it’s that they struggle with setting up Create React App, or they don’t know how to deploy these things… Or maybe they’re just more comfortable with different technologies. We would love the system to be more agnostic, to be able to address those needs, but that also requires a lot of work and investment… So we’re also trying to figure out what are the best ways to support them without also slowing down our progress.

A really good example of this is if someone came and told us “We want you to support Figma, Sketch, Framer, React, Android – I don’t know what Android [unintelligible 00:17:09.23] these days), iOS… All of these different technologies. Say that we added a new component, so we added a new property that changed the size of something - we’d have to do that in each of those technologies. So those changes become - they scale at an exponential rate, every thing that we have to support. So we do have to be a little bit opinionated and try and guide the community, but we also really wanna support them. So yeah, back to your question - we don’t really have a great process right now, but I think that’s what we’d love to explore.

The thing I love about this open research - you touched on it, Alex, when you mentioned that the Vanilla Extract team has been in touch. You all very well laid out, “These are the alternatives that we are analyzing… And it allows the people who are involved in those communities, whether they’re the maintainers, the creators themselves, or a happy user (or a not so happy user) to hop in and weigh in… I just thought it was so cool that, for instance, TheMightyPenguin - which is a great handle, by the way - who is the author of dessert-box, which you all seem to be using, or at least looking at… He hopped in there and he took the opportunity to get some feedback on his API, like “Hey, why don’t you like this API? What’s hard about it?” and have a back and forth with you. So that was awesome.

In light of that, did you all promote this discussion? Did you contact the folks? How did everybody find out about it? Because a lot of us open up a discussion and, you know, crickets. How did you get attention to this particular effort?

Sam, I think you know this story…

I don’t, no, actually. You seem to be the famous one here, and to be able to get the attention.

[laughs]

Oh, yeah. I know what I know, and I know – I think it’s May, a really awesome design system community builder. She has a newsletter, and I think she actually picked up on some of our open source work and was watching it… And I can’t remember the company that May works at, but I really appreciate May for doing this… But she was going through a similar challenge at her company, so she was very interested in seeing our exploration and research… And she ended up sharing that in her newsletter. And from that newsletter, other people saw it and started sharing it.

I think some of the virality of that tweet, or engagement, was also around “Shopify is replacing Sass”, and I don’t know if that’s necessarily entirely true. I think we are exploring alternatives to Sass in our design system, and we hope that these frontend opinions that we have as a design system team would scale to the rest of the company… But there’s no “We’re removing Sass” or “Sass is terrible for [unintelligible 00:19:45.25]” We actually love Sass at Shopify. We’re still using Sass today in our major products, but we definitely have some concerns with the scale of Shopify and Sass that we can get into a bit later… But yeah, I think it was just May’s newsletter which was really awesome to get that visibility, so we really appreciated that.

[20:03] As an aside, I don’t think we necessarily wanted that visibility just yet. We’re still experimenting and exploring, and our opinions definitely could change over the coming months… But we appreciate it nonetheless, because it’s been a great learning opportunity to just put it out there and work in the open and really embrace that culture. I think that’s what we wanna build on our team, and scale - this is how we work and this is how we solve problems… Even if it is a little bit uncomfortable and someone can find it and put it in a newsletter and get more visibility. I think that’s a problem we would like to have instead of not have.

If I could add on that - that’s something I think a lot of people are maybe a little hesitant to do, is to broadcast work too early. I would certainly think we’re at very early stages in this prototyping and experimentation, and a lot of learning is going on… So this kind of publicity really – at least showed myself that getting the community involved and having this attention early on is really not too much of a bad thing. It’s not a bad thing. Again, you could arrive into that “Too many cooks in the kitchen problem”, too much early feedback… I certainly have been surprised with how that has not been as much of an issue I would have expected it to be.

Break: [21:10]

Alex, I think you spoke some truth when you said some of the interest in this particular discussion is this replacing Sass. Sass has been around for a very long time, and it’s helped a lot of us be more productive for many years… I’ve never seen a “replacing Sass” discussion until I saw this one, so I was like “Whoa! Replacing Sass.” And then, of course, Shopify - y’all have a big application in business, and so people watch what you do and take note. Because when you adopt things, maybe it’s worth looking at, and when you ditch things, maybe it’s worth ditching as well. I think that was one of the reasons why this discussion did gain steam on the interwebs.

Tell us about Sass in more detail. The history of it at the company… Like you said, you’re not here to diss on it or hate on it or anything like that, but you are looking for alternatives. So maybe some of the warts, or some of the things that you’ve hit up against, where you decided it would be worth this effort to maybe replace it with something else.

Yeah, totally. I’ll kick off. Sass has been a phenomenal technology at Shopify for us to scale design decisions and opinions. Even before I joined Shopify, I worked with the Australian government, building a design system there… And we did some (I would say) really advanced things with Sass. We had functions that would find the closest accessible color… So if you had a white foreground color, and a white/pink background color, it would correct that white foreground color to be like a dark pink foreground color. So we have really advanced functionality and solutions to things in Sass.

[24:20] I think Sass is an extremely powerful tool for solving design problems at scale. I think lots of people - I would even encourage - should still use it today. But Sass with Shopify – like, Sass has been at Shopify long before I’ve joined. I wouldn’t be able to tell you the date that it existed, but it exists in our legacy almost like Rails infrastructure, where we have things that were built maybe even in the first days of Shopify… We have Sass in our React infrastructure, where we just use the Sass files and compile them into CSS, or we already have the compiled CSS and use the classes from the Sass… We have so many applications for it.

I think currently in Polaris React we have 152 Sass files, we have 2,000+ Sass files in our biggest monolithic repositories… And some of the things that we’ve really noticed as a design system team is that we haven’t really scaled, I would say, our design opinions in a way that is working with Sass right now.

Some of the things that we’ve hit up against is we’ve created a tokens library. This tokens library is almost like a tech-agnostic library that we could use in Figma, or we could use in HTML, or we could use in a mobile application that has color values. I think it has a few motion values, and things like this… But it doesn’t have everything. It should realistically have our spacing values, it should have a whole list of all the things that sort of define Shopify’s design. So where are these other values? Well, they’ve kind of spread between lots of different technologies. Some of our these JSON values in our tokens library get converted to CSS variables. Some of them get used as Sass variables and Sass mixins and functions. Some also just get imported into the React code and used that way, which is really bad… But we lose a lot of control over how we wanna scale those design opinions, as we’ve scaled as a company. CSS variables came out, like “Let’s use CSS variables”, but we never really cleaned up that Sass technical debt, and we never really put those variables all the way back into those tokens libraries. So that’s a tension that we have.

But I think the things that are more of a tension as a design systems team is that we ship Sass. And in shipping Sass to our users, they can use our functions, they can use our Mixins, they can override our variables… And this becomes really scary, maybe because if we wanna go and make a change to something, we don’t know what this could affect, or what this could impact at any time right now. So if we went and said that our primary button color is changing from green to purple, and they’ve got a function which takes that primary button color and maybe blinds it by 20%, and it does this for some very specific reason about this icon on this one page that they actually wanna be a dark green, and then we go and replace it - we get ourselves into a world of confusion and trouble, trying to update and scale these design decisions.

So what we’d love and what Sass doesn’t really offer to us right now is a way to obfuscate or make it really difficult for those consumers to override those things, unless they use our approved methods of overriding them. So that’s sort of the direction that we’re heading in - we would love to be able to trust these teams and things to use the tools in the ways that we encourage, but it’s also really easy when those APIs exist or when there’s a little workaround that you could use that just touches on that… Why wouldn’t you do that? But then the implications of that become so much more, and we need to go and change a function or a mixin or a way that we’re solving a problem.

Sam, maybe there’s some things you wanna add. I don’t know if I’ve touched on everything.

[28:09] No, I think you’ve covered a lot of great points, and some that I really wanted to touch on, like - with how some of the next explorations we have done really do help solve a lot of those problems.

So you identified these things… What I like is you’ve very clearly stated your goals of what it is that you are looking for; what matters most for Polaris, and then specific criteria. So when it comes time to go ahead and do the survey, you’re not just at the whims of what you feel like, or what looks nice… You can create a matrix table and check the boxes and say “Does it do this? Does it do that?” Do you wanna walk us through some of the things that are in that list of goals and why they’re important for you?

Yeah, I might kick off… But just quickly, shot-out to Marten Bjork. He’s a developer on our team; creative technologist actually on our team. He sort of sits between design and development… And he actually said – he was looking at our research and he said “This is confusing. Can we do a matrix table of it?” And then he even went and said, “Let’s add user stories”, which was awesome. And I think [unintelligible 00:29:14.10] and a few other people on our team - maybe Chloe - had an idea of sort of prioritizing these. So it’s definitely not our – it’s very much a big team effort in how we came to this table…

Some of the things that we have on this table are like zero runtime. We love when things just work and don’t impact our users, and Sass is a great example of that. When I use Sass, I take the burden as a developer of converting that Sass to CSS [unintelligible 00:29:41.23] They don’t have to run anything in that browser to convert that Sass file to CSS. It’s awesome. We love how powerful that is, and that was something that we thought was really important.

[unintelligible 00:29:55.18] as a user, I don’t want any additional code or processing time spent for me to see styles… And we went across these different technologies, and we looked at things like Sass, and CSS, and we were like “Yeah, these are zero runtime. You compile the Sass into CSS, the user gets the CSS file. If you just use CSS, the user just gets the CSS file.” And that’s a really great way to explore and understand these things.

But some of these things I would say are also our opinions. We said that some things are not zero runtime, but maybe we have some plugins or some different ways of approaching using those solutions. They could become zero runtime, but we really want to focus on what does the technology give us today without those things?” Because it’s really easy to add 30 plugins or write custom code and solve problems with stuff, but as a company like Shopify - maintaining that and scaling that to all the teams, that’s when it becomes a lot harder or a lot trickier. So we have to be a little bit careful there. But Sam, were there any [unintelligible 00:30:52.25] you wanted to talk about?

I would just say maybe when constructing a matrix like this, something to be more objective about making this technology choice, just really considering those factors that apply to your company or your product, your team design system etc, simply because – I mean, we did leverage a lot of other research on CSS library analysis, very thorough work that other people have done… But just putting it into this matrix within our own context and what we prioritized and needed in this solution I think is really just something to keep in mind.

Divya, are you looking at this matrix? It’s awesome.

Yeah. Was the way that you evaluated just sort of coming up with the criteria, to some extent, as a team, and then did each of you sort of pick a library to then do a spike on, and then from there come together as a team and then talk through the various features?

[31:47] I would say that was well summarized. We definitely did truncate the list of libraries to explore pretty short. We did try to diversify across some that were more runtime specific or CSS-in-JS, StyledComponents-esque; others that were a little bit more utility-based, like Tailwind… So we kind of tried to get more of a diverse set of libraries to examine. We did not look at StyledComponents and Emotion. We kind of bucked at those similar things; they both have their pros and cons, but… That was kind of our strategy.

But when we did do our analysis, we did put some time forth and kind of explored them, prototyped with them… Not just kind of look at their feature list and check it off. We really did want to get hands-on experience and feel how the library was to work with, what was the developer experience like, would this fit into our tooling well, how easily would this be to adopt at scale… Those kind of questions. Alex, do you have anything?

No, just a big +1. The only thing I’d add is our team is growing and getting pretty large, and there are people that have worked with these other technologies in other companies, or have experience using them as well, and that really helped us build some opinions quickly… Because some of these comments would be like “Oh yeah, I’ve used this tool before. I know what this should do or shouldn’t do.” Or some of them were like “I don’t know Tailwind does this at all. Let’s go spend half a day exploring the ins and outs of this library and see if that would accomplish the needs that we have.”

I’ve just noticed that a lot of these criteria were just various things that are really important, like zero runtime, how to overwrite styles, and so on. Was a consideration also the migration strategy? Because the end goal is that you have a new system, but the in-between transition phase is always the awkward one… So how did you actually think through that part of things?

Yeah, I think that’s honestly something we’re still figuring out. We’re doing a bit of an adoption plan right now, to say “If this is the output of our system, how would teams consume this or use this with the Shopify tooling and technologies today?” We definitely care a lot about that adoption, and we’re working closely with a few partner teams, and that’s something that I’m really excited about. We’ve partnered up with a few internal teams and we’re gonna start experimenting with how does it feel to use these things, is it as you would expect, are the APIs useful? Or are they hitting roadblocks, and what are those roadblocks, and are they roadblocks that we can get over, or are they hard blockers?

So we definitely are, I would say, early in that understanding the impact of that migration, but we’re partnering with a few teams internally at Shopify to really understand what they need from the system and how these changes could impact that.

I would say that the things that we’re looking at right now have similar processes to the technologies that we were using in the past, Sass and Vanilla Extract… Even though they’re two separate worlds, they both have a file type that ends up being a CSS file. And that is really awesome, because it means that that journey that our contributors or teams need to learn hopefully should be a lot more simpler, or we should be a lot more straightforward with some guidance and documentation. I think that’s the other missing piece - we need a lot of documentation and explanations around why these things were chosen… And that’s some of the reason as well for open sourcing this research - it almost is a starting point for us to be able to write guidance and documentation. Why did we choose this? How do we expect this to scale? How do we expect you to use this? What changes for me as a frontend developer at Shopify when I have to use this technology? I think that all hopefully will come out of this.

So let me just draw a quick word picture around this matrix that the four of us are looking at, but our listeners are definitely not looking at. By the way, we will link it up; it’s in the chat, so if you’re in the chat, click through on that. If you’re not in the chat and you’re listening to this in your podcast app, click in the show notes… Because you wanna check out this matrix. In fact, if you steal one thing from this episode, I would just steal this matrix outright and use something similar for your own research.

[35:47] Imagine a list of features are the rows. So we mentioned open source, along with the user story, which is a nice to have. As a consumer of a library, I wanna contribute, request features, resolve issues and debugging the code. And then the different solutions are each columns. So you’ve got Sass, CSS, Tailwind, CSS Modules, Stitches, Vanilla Extract with sprinkles, and Emotion. So for each of those features, you score each solution on a scale of 0 - I’m assuming 0 means that it does not fit the bill - 1, which is yellow, so I guess it’s kind of good, and then 2 is green, which means “Yay! Awesome.” Maybe you guys can help us understand the color system and the numbering. And then you go down the list and you add them all up and you see what the score is at the bottom.

What I like about this, before you help us out with the scoring, is the features are not just listed out; they’re actually broken out into categories. What’s essential, what’s important, and then what’s nice-to-haves. I think that’s a great practice for anybody trying to make a decision, is to prioritize what really matters, what you’re optimizing for, and make your decisions based on that order, versus just like a random list of things you want. Help us out - 0, 1 and 2. Are these quantified? Because it seems like they are.

Yeah, I can talk a little bit to that. These are our opinions, again, on “Does it do what it says out of the box?” And the emphasis there I think is “out of the box.” If it does it, it gets a two. If it does it, but it needs a lot of configuration, or it’s a lot of technical debt to maintain, or it could be a pain for us to maintain or consume, then it’s a 1.

I think a great example that I can think of is autocomplete in Tailwind. For me to get autocomplete in Tailwind I have to install a VS Code extension. So for me having to then go and document that to our users if we did use a solution like Tailwind, it’s like “Oh, you should use this plugin.” That’s an extra step every user of our design system would have to take to get that autocomplete functionality. So I’d just call that a 1, because out of the box you don’t get that functionality. But it exists. And then a 0 is just - yeah, unfortunately this feature doesn’t exist… And again, that’s our understanding of it. We could be wrong, and I’d love to learn as well if people look at this matrix and they disagree. Feel free to chuck a comment in there and tell us. We’d love to learn.

So we wanna talk about what y’all found, because that’s like the [unintelligible 00:39:43.26] At the end of the day, you’ve put all the work in, you’ve found a solution, and you’ve picked one. We’ll talk about how you go there. But before we get into that - of course, the aggregate scoring will come into play, so stay tuned for the way these different solutions score… But how do you even find the options? Because discoverability is a thing, and people are talking about Tailwind… I had never heard of Stitches… I think I had heard of Vanilla Extract, but I had never clicked through. I’ve heard of Emotion… But how do you all find solutions? How do you collect them? Maybe you say “We’re not gonna check that one out.” Is that a thing that happens before you get to this stage, like “What are we actually gonna try?”

I can take that. I would say largely relying on others’ experience, both within our team, but also there’s a lot of (like I mentioned) other research, people who have already done comprehensive assessments or comparisons of these different libraries. With CSS-in-JS, since it’s become a thing, over 50 libraries, how do you make that choice? How do you find something that is as strong as a Sass has become? But that comes back to that point of what seems to have a large community support, what seems to be well-liked, well-adopted? Tailwind out of the gate screamed at us, simply just because it’s been highly adopted and well-loved by a lot of other developers.

So creating this list really was just, again, comparing what are our needs, and then what solutions, top 10, top 20, can we parse from really quickly and just see “Do any of these fit the bill? Do these seem to be scoped well for what we’re trying to achieve?”

Yeah, we have to be a little bit harsh at the start as well, because there’s an infinite number of solutions right now for how should CSS get delivered to the browser. You can make something up even yourself if you wanted to. I’m sure someone’s doing that right now. But we have to start with a bit of a baseline of like “If Shopify was to adopt this, would it disappear tomorrow?” If it’s gonna disappear tomorrow, we probably can’t use this. Some opinions are a bit more fleeting, or unused, so I think tools that are widely used, like Tailwind - that fills me with confidence, because I don’t think that’s gonna disappear any time soon. If anything, it will evolve and it will just keep growing with the huge community behind it.

Vanilla Extract, however, is quite new, but it already is used in a few design systems which we really love, which gave us more confidence we could sort of explore and understand it. And it wasn’t a hugely technical project; if you dive into the code - yes, there are technical and challenging areas, but the things that it was doing were a lot simpler than other things, mainly maybe because it is a new(ish) project; they haven’t built maybe all the different layers… Or maybe they have; I don’t wanna talk for their team. But it made it a lot more, I’d say, accessible and easier for us to look into those sorts of solutions.

I’d also add - not looking at just the solution itself, but the characteristics of the solution was really helpful. So knowing that Tailwind was liked - is it because its utility classes, is it because of Atomic CSS? What characteristics are loved because of – you know, like, Chakra UI uses styled-system and Emotion. Why is it loved? What kind of those characteristics about these systems or about these technologies influences adoption? So that’s kind of one thing that spoke to us as well; it kind of helped narrow down the choices.

So let’s get quantitative, shall we? We have some totals here, at the bottom of this matrix. The first one is Sass. Of course you had to score Sass, because that’s the base case that you’re comparing all these against. It scores a 37. So if you just take the list of 30-odd features that you all listed and then the scores from 0 to 2 for each feature, Sass totals up at 37. Plain old CSS scores a 39, which I thought was pretty nice. Tailwind a 44; take note of that one, because it will not be any higher than that. CSS Modules 21, Stitches 32, Vanilla Extract 38, and Emotion 31.

What hops out to me right away - and maybe, Divya, you caught on this as well - is Tailwind is the winner on the quantitative, but it’s not what you all have decided on, is it?

[44:06] Definitely. And I think there’s a few things going on. One, we were just a little bit lazy, and we’ve totaled the whole table up… So that even includes nice-to-have things, important things, maybe things that we don’t care as much about… And I think it would have been interesting to look at the scores from the essential and the important. It’s not gonna change it too much; there’s only two columns in there, really… That would have changed things up.

But I think also - the numbers only mean so much. The numbers help us guide to – we think maybe we should look at these four things, or maybe we should prototype with these four things, and that then helps us go and decide what we want to explore, or dive a bit deeper in… And then we can from there make a better decision.

The decision that we ended up making was we wanna explore using Vanilla Extract, and that’s what we’re doing right now. We’re using this library to explore again a bit deeper. I think Vanilla Extract scored third on our list, so it’s definitely not even the top two… But if we look at the top two, like Tailwind and CSS, CSS would have required us to either lose – and maybe “lose” isn’t the wrong word, but it would have empowered teams to be a lot more flexible, but it would have made our job of maintaining and updating the design maybe a lot more challenging… Like, if every team is writing their own CSS files, and instead of using our spacing CSS variable they just hardcoded 9.25 pixels, then we’d go in and change our spacing scale, which changes all of those variables… That would mean that we’d have to go back in and find all these hardcoded values. And as someone who’s done that at a company like Shopify - not fun. Really, not fun. It’s really time-consuming. You’re jumping up across multiple codebases, and repositories… So it’d be great to have that in a scalable way. I still think CSS is awesome, though. The ability to just trust people and give them that empowerment to make the design decisions that they need to - I also love that. But it is a balance, and we need to make a decision as a design system team and as a company of where does that balance sit.

And Tailwind is also another excellent solution, but there’s just some concerns that we have around scaling Tailwind as a company at Shopify. We already have 20,000 Sass files… I think it was 20,000; or 2,000? I can’t remember off the top of my head. Let me double-check. Yeah, 2,000. 20,000 sounded way too much. So we already have over 2,000 Sass files, and I think that if we were to use a library like Tailwind, things like the just-in-time compilation, we’d definitely want light and dark mode, we could have maybe 2,000+ React files with those classes that it’s auto-completing and adding to… It just feels like it’s a risk right now to invest in a product like that. Also, we don’t know if Shopify wants to have more than just light and dark mode, and Tailwind right now has really strong support for light and dark mode… But as soon as you add a new color variant, like maybe you wanted a dim, or an extra dark mode - that would then have to go and generate all the color CSS classes again, and that means that there’s more just-in-time compilation and there’s more CSS classes getting added to HTML. And it’s not that we think that’s necessarily a bad thing, but how we scale that and make sure that it doesn’t turn into a big mess at Shopify is something we’re concerned about. CSS variables - that approach feels a lot more powerful, and if we can have classes that we can override with CSS variables, that empowers us to move a lot quicker. But Sam, is there anything you wanted to add about the total scores?

Yeah, I would just say this was only one way of parsing through our observations and attributes that we are interested in. If we wanted to go be less lazy, and put weights to the different importance – have weights, and “What is a non-negotiable? What’s something that’s a nice-to-have?”, make these scores a little bit more refined, we could certainly do that. This was really more just a scrappy way for us to take the mental model of saying “What do these libraries have as a larger picture?” Kind of zooming out and putting them side by side… And really just being more data-informed, giving some kind of objective criteria. It could be more accurate, but I think we kind of understood our requirements, and by prototyping with them hands-on, that was a lot more informative for us. But this was certainly a more objective way of looking at it. So yeah, again, I think these scores could certainly be refined, but it definitely helps serve our purpose of assessing these solutions.

[48:37] Yeah, I was gonna suggest that for an iteration on this; if you’re gonna steal it, I would say at least weight the three categories, so that the more important things get more scores, and you probably would have a better reflection of the final decision.

For example, in the discussion you made it sound like TypeScript support was pretty important, and it’s in the important features section, but in this representation it doesn’t seem as much – maybe I read in too far, but it seemed like that was a pretty important thing… And a couple – this is kind of an all-or-nothing thing, like “Do you have it or not?” and I think probably it might not be representative of how much it meant to y’all. Is that fair?

That TypeScript support one is very interesting, I think, to pull out… I think Vanilla Extract [unintelligible 00:49:18.16] with TypeScript support, but it’s different to the other libraries. When I think of TypeScript support for CSS, that just sounds weird, and that’s like the special place to me where Vanilla Extract lives - as I create a grid component and I give it a gap value, I’m auto-completing instantly from a list of spacing tokens that comes straight from our library of atomic styles. That’s through TypeScript, and that is so powerful, because I haven’t had to add an extra feature, I haven’t had to do anything to Visual Studio Code… I’ve literally just opened up this TypeScript project and it knows through the linked types that “This is auto-completing from these values.”

So when I think about TypeScript and CSS, it’s less so TypeScript and CSS, it’s more like “How can we get autocomplete into CSS?” or “How can we autocomplete from CSS our specific CSS variables that we’ve approved?” And our team in the past - shout-out to [unintelligible 00:50:18.03] - he wrote a full CSS variable linter where he would go and parse our code, check if there were people using incorrect CSS variables, or if there were typos… That’s extra technical debt that we have to maintain. It was an awesome solution at the time, but if this was just built in to how we did styles, that would mean that we could sort of just ignore that completely, which is such a powerful thing.

So I think that’s a huge, exciting feature for me around extractors. I feel like this combination of TypeScript and CSS is something that I haven’t seen before. Just as an aside, I’m terrified of TypeScript; I’m terrible at TypeScript. If you give me some crazy override or something like this, I will be the first person to trip and stumble… But what I’m talking about here is a lot more like properties auto-completing with values that come from your tokens, or come from your CSS variables. And that setup and that time that we invested as a team to get that setup is so worth it… And it just feels – as the person using that system now, it feels really great to just easily see those values pop up and move quickly. But Sam, you know much more about TypeScript than I do, so maybe you wanna add something to that.

I would just maybe add that it’s not just giving values… Really just hammering on the design system values. Really making it easy and apparent like what values are part of the system. You know, a lot of these solutions have theming support, but I think what’s really nice about something like Vanilla Extract is it really has type support for both the design system values, as well as the atomic classes… Because we mentioned Vanilla Extract with sprinkles; that was kind of the nice thing about it - it brought that Tailwind factor into it. We mentioned you could have these IntelliSense third-party add-ons for TypeScript to autocomplete certain utility classes.

[52:10] We have autocomplete with theming support in a lot of TypeScript solutions, CSS-in-JS solutions… But this really kind of combines those two worlds, and it brings it to a technology that’s already within our Shopify ecosystem. We’ve all adopted TypeScript. We don’t have to add anything new. There’s no extra server running to check or lint, so it kind of just meets us where we are, in a way.

So the Vanilla Extract team has to be happy… This is like they’re on The Bachelor and they got the rose.

[laughs]

You fell in love.

Did the conversation with them have any impact on the decision at all?

No. We had never talked to their team until after they saw that we were using their product.

Oh, no way.

Yeah, we would have loved to have talked to them beforehand… But just as an aside, we don’t really wanna bias our opinions based on talking to this team or another team. I’ve talked to a few people that work at Tailwind, like Simon, who does all their videos; I’m a big fan of his work, and I’ve hung out with him a few times in person… That doesn’t mean that I’m gonna use this product, unfortunately. The reason we use that is because we actually explored it and wanted to, and then those connections opened up from that, and sharing that research… Which was really great.

In terms of them getting the rose - maybe… I think that we as a company want to invest in open source, we wanna collaborate with these library maintainers to help them get some attention. I definitely think the Vanilla Extract team deserves the attention. They’re a team of three, doing excellent things [unintelligible 00:53:43.22] in Australia, to build a design system and a whole bunch of tooling around it… And if we can put a Spotlight on the awesome work that they’re doing and get other people to think about using it, that not only benefits us, it benefits them, it benefits that community around that tool and that platform. So yeah, maybe they get the rose, but I never saw it as that; it was more like we needed a solution, and that seemed like a great solution. If there’s an outcome of that where they feel great that we chose that, that’s awesome. But it wasn’t necessarily our intention.

Well, I think they definitely deserve the attention, and it’s awesome that they’re getting it now. Divya, maybe we should bring them on JS Party and give Vanilla Extract–

Yeah, I was just thinking that… Like almost an extension of this episode; like a part two, where we’re like “Hey, we need to talk to them, just to get a sense of–” Because there is a newer library, and I think the usage is not super-high at this point… But we could definitely bring visibility to it.

Mm-hm. Stay tuned for that; let us know, listener, if you are interested in that. And I forgot - Sam, your last name is Rose, so this was the perfect analogy. [laughter]

It is. I usually make those puns, but… I saw it in my head, I just didn’t say anything. I was like “Ah…”

Well, you had better taste than I did. I have no shame, I’ll just–

I’m just shocked that you used The Bachelor’s metaphor… [laughter]

It’s a cultural staple at this point… I mean, how long has that show been on? Probably like 20 years.

But that’s not the metaphor I would have reached for personally, I guess, but…

Fair enough.

…I’m just tickled that that’s the one you used.

[laughs]

I liked it. I thought it was [unintelligible 00:55:22.29]

I was gonna go with Survivor, but…

You got booted off the island…

Yeah, exactly. Kind of the other way around… So guys, what’s next? We’re getting towards the end of the show, but what happens next for y’all? Is it still kind of an experimentation phase? Are you starting to integrate Vanilla Extract into Polaris? Do you replace it one file at a time? What’s the point of it?

[55:45] I’ll kick off… We’re like exploring right now. I think the first step is get this to a state where we can get other teams using it, and then start getting feedback. So our biggest goal right now is get this into the hands of internal teams, so that we can figure out what’s working, what’s not working, and make this the product that’s going to accelerate Shopify into the future. I think that we have a lot of work to do to make sure that this is the right solution. We have Rollup tools right now that use Vanilla Extract, and for us to use Vanilla Extract with Rollup we have to have some kind of opinion on how we wanna bundle those CSS files together… But maybe, Sam, you can take over, because you know a lot more about the next steps from the technical side that we’re gonna be exploring.

Yeah, you mentioned migration strategies and adoption plans - that’s what we’re really focused on now. Now that we’ve seen the technology, we understand that this could be very right for Shopify, and we think it can scale, we think it’s really good for what we’re calling a foundational base to build upon… But again, making it easy to make those design system choices and kind of adhere and flex the system and make it flexible for the factors or whatever the products that we’re delivering at Shopify. That adoption and roll-out plan is what we’re working on now.

So we kind of better understand the technology and now we’re working with other teams within Shopify to integrate it into our common build systems, and making sure that it’s seamless and easy for Vanilla Extract to be used and understood across Shopify.

Some of those reasons, like we’ve mentioned - it is very similar to Sass, in that it’s like a .css.ts file, [unintelligible 00:57:17.10] but it’s used similar like CSS Modules, which we’re already using today… So that adoption we do hope is going to be very smooth, but it’s really just figuring out a lot of those technical details and getting the build integrations figured out.

Awesome. Well, we’re happy that y’all did this research in the open, in the public, and allowed our prying eyes to check it out and learn alongside you, see how you made your decisions, what was important to you there, what you looked at, how you ranked it, so that we can go out and make our own decisions a little more informed than we would have otherwise. So pretty cool, guys, Sam and Alex. Thanks for coming on JS Party and talking us through this entire thing.

Of course, all of the links to all the things are in your show notes; especially that matrix is in there, the discussion thread, and a link to each of the six solutions - I guess five, because… Can you link to CSS? We can find a way; we’ll link to it somehow, probably the MDN article… They will be in your show notes, so you can check out all the different options that they checked out for yourself. Any final words, guys, before we call it a show?

Just a huge thank you. Thanks for letting us come here and talk. I’d love to see the Vanilla Extract team on there, and sharing their technology. I think they do a much better job than we did of like pitching or explaining the different ins and outs of it. Thank you so much. It was great to be on here, talking about open research, and open source, and design systems. Thank you so much.

Yeah, just +1. It’s been a party. Thank you.

You bet. Well, we definitely are interested in doing that episode, so let’s make it happen. Stay tuned for that. Divya, thanks for being my co-pilot today. Happy to have you back.

Good show.

Good show. Alright, that’s JS Party for this week. We will talk to you next time.