Kate Trahan:
Okay, welcome to PodRocket. I'm Kate, the producer of PodRocket. With me hosting it today is Noel. Hello Noel, how are you doing?

Noel Minchow:
Good, good. How are you, Kate?

Kate Trahan:
Thanks for joining us as the host today. And then our guests are Alex Page and Yuraima Estevez from the Polaris design team. Hello, Alex and Yuraima.

Alex Page:
Hello.

Yuraima Estevez:
Thank you for having us. Excited be here.

Noel Minchow:
Awesome, yeah. So I think to jump in with, maybe we should frame what Polaris is and what its role is with Shopify, particularly for those listeners who aren't familiar with the Shopify ecosystem and the purpose it serves. So can you set that up a little bit? What's the mission of the design system? Why is it needed? Who's it for? Kind of play that out?

Alex Page:
Yeah, I might start and I'll hand it over your Yuraima at some point. But Polaris has been at Shopify since way before I even joined. I've been at Shopify for three years now. It is a design system. Obviously, there's lots of layers to what is a design system. So when we talk about a design system at Shopify, we're talking about the website which contains guidance. So lots of guidance around how to write content, how to design patterns, how to create different flows in the UI. What we think of when we building different experiences, I think of our components and our code that comes with them.

Alex Page:
So what makes them accessible, performant, scalable, how they allow people to build up different patterns and solve different problems? So there's lots of interconnecting pieces, but the reason for all of this existing is we need a way to enable our designers and developers to solve complex problems at scale, and that's the real point of this. So why do we have this guidance and why do we have these components, and why do we have this website and these repositories? It's because we want to solve really complex design problems at scale, and code and tooling and guidance is the ways that we believe that we can do that. Yuraima, do you want to maybe talk a bit to our mission and what we're aiming for?

Yuraima Estevez:
Yeah, totally. So our mission for this year is, I would say, pretty ambitious. But I believe that we can definitely hit it for 2022. As Alex said, the design system itself is for the Shopify admin. So the admin is the bread and butter of Shopify, it's where all of our merchants can manage their orders, their products, their customers, and we are building the tools that enable designers and developers to build the best products for our merchants at Shopify. And our mission this year is to make sure that 90% of the admin, 90% of our bread and butter, as I said, is using Polaris.

Yuraima Estevez:
And the reason we want to do that is so that everything we build in the admin is always getting the best components, the best performance, best accessibility, and is consistent across any product, any team that is working in the admin, any experience that the merchant is in, page section, whatever. So really just making sure that we have a consistent experience across all of the admin and hitting that high bar of 90% so that, at any point, if we need to make any changes to the Polaris design system, we can more or less click a button or release a new update and say, "Okay, the majority of the admin now gets to benefit from all of the amazing changes we've made."

Noel Minchow:
Gotcha, gotcha. So how are you working towards that goal of adoption? What does that look like?

Yuraima Estevez:
So I think we started this new goal, I'm going to say in earnest, this year, but it's something that we've been talking about for many months. This year we kicked off, or actually at the end of last year we kicked off a new project to really think about what is Polaris design system at the foundational level, and how is it surveying our users, our designers and developers, and how is it falling short? So taking a really hard look at the mirror and basically saying, "Where can we do a lot better?" And the thing that was most obvious was our design system is a little too rigid. It was built with a specific purpose. And as Shopify, the admin, the number of people working the admin grew, so did the complexity of the admin, and in turn the complexity of the design system.

Yuraima Estevez:
And now it's gotten to a point where it's too rigid, it is a little bit too flexible, and we're taking a step back essentially and deciding to go back to the foundations, go back to the base layer of Polaris design system, and say, "Where do we make the most significant changes that are going to provide the most value?" A lot of it is taking a look at our primitives, our really baseline components, and saying, "Can we break this down further? Can we make this more flexible, more atomic, so that our users can come in and just pick all the things out that they need for what they're building and use it in whatever way they need?" Alex, please feel free to jump in if I missed anything.

Alex Page:
I think that's good. It's really tricky when we talk about adoption because it comes back to what our users need, and our users need so many different things from a design system team. It could be, "How do I frame this sentence?" It could be, "How do I build this little piece of the UI?" So we have an unlimited number of problems. So what we've been doing recently is just trying to go and ask why, to Yuraima's point of getting down to some of the root cause problems. If you ask why enough times, "Why is this component so large and so different and so custom? And why can't we put this into the design system?"

Alex Page:
We'll usually end up with an answer which is like, "There isn't enough flexibility in layout at this points in the UI, and we wish that we could create this thing in a way that was more scalable." And then we want to solve that problem. And so when we're going through and supporting and helping these teams adopt the system, it's really trying to find those deep, underlying problems at the heart of the system instead of just being like, "Okay, cool. Let's bring all your problems into the system and then we've got more problems in the system, but we've got higher adoption." So I hope that makes sense.

Noel Minchow:
Yeah, yeah. Totally. I guess maybe to help us frame it a little bit more, and you guys are talking about working with teams, is that mainly internal teams or are you guys working with external design teams and devs as well?

Alex Page:
That's a really good question. We have multiple users. So the primary user that we do focus on are the internal teams building the admin product at Shopify. So the admin product is when I am a merchant running a store, I log into shopify.com/admin, and I'll see a list of all of the orders that have come in that have been bought from my store. I can see a list of my users. I can see a list of my products. I can go into a details page of lots of form elements and edit those things. So realistically, these people building these UIs, these lists and these forms and these flows, this is our primary audience. But the Polaris design system does also have a really strong mandate to help also our third party and our developer ecosystem.

Alex Page:
So there are a lot of people externally that contribute to building on chop platform. They'll either be building applications or they will be building integrations with how Shopify works. And sometimes they want their UI to feel a part of the application or a part of the system. They want it to feel like it's a first party experience. So we try to build tools and experiences to make their life easier as well. We don't want people to want to build or have an excellent idea about gift cards, and then have to build everything from scratch. We want to get some really primitives, accessibles, some examples that they can configure together to solve that problem. Yuraima, is there anything you would add around our audience? It is an open source repo too. You could maybe talk a little about that.

Yuraima Estevez:
Yeah. So as Alex said, we have our third party developers that are external to Shopify, but still working within the Shopify ecosystem and building out really amazing tools for our merchants. So in order to give them that really solid base and starting point, we have the Polaris design system open source, available. It's actually how I learned about Shopify was in the design system space. Polaris is, I think, one of the more well known design systems, and I knew about Polaris far before I knew Shopify and then realized, "Oh wow, this is a really good starting point for building out any sort of tools that are meant to be living inside of this Shopify admin ecosystem." So we do have that third party audience and then the internal audience we mentioned already, the designers and developers at Shopify working in the admin.

Yuraima Estevez:
A lot of times we will partner with them to help maybe support when they are coming up with new ideas or if they're struggling a little bit with any new products. Sometimes they will come to us and say, "Hey, we have this idea for contributing this back to the Polaris design system. Can you give us a little bit of support?" Or sometimes folks will be like, "Hey, we have this product that we need to build. We're not quite sure the right way to go about it. We know that the design system has some guidelines, but our use case is maybe a little bit more nuanced or bespoke and we want to go about it the right way." So it really depends the team, the individual contributor, but it is this two-sided audience of internal users, designers and developers, and then third party developers who are external to Shopify who are also building in this ecosystem.

Noel Minchow:
Nice, that's interesting. Yeah, so Yuraima, you said you were familiar with the design system before you even knew it was tied to Shopify at all. Is that right?

Yuraima Estevez:
I knew about it and knew about Shopify as, "It's a company." I had no idea what Shopify did. I had no idea it was e-commerce until I looked at Shopify and was like, "This is awesome," and dug a little bit deeper and was like, "Oh okay, so this is specifically for the product that they have built, the e-commerce platform that they have." So it was great because it's an amazing design system in and of itself, but it is also built with the specific purpose of working within the Shopify ecosystem, specifically for the admin, specifically for the designers, developers that are working in that space.

Noel Minchow:
Gotcha, gotcha. That kind of leads to my next question then of is there any use case outside of the Shopify ecosystem, or are the components pretty closely tied to Shopify APIs and data fetching and stuff like that?

Alex Page:
There's no API connections. Actually, sometimes frustratingly, we'll have a really big component like a resource list, and it will give you very light guidance on how to set that up. But when you want to set up sorting and filtering and populating the data in those lists, that's a lot of work for you and your team. And I wish we had better examples for that, but that flexibility means that you can use it for lots of different things. I think where there's more strictness with it would be on the design side.

Alex Page:
So if we looked at our page component, which is a very opinionated component on almost how a form page should be structured at Shopify, that has very strict layout and typography and positioning your buttons and things like this. And if you were going to use that page component to create a blog, I'm sure you'd get really frustrated really quickly with the layouts and the opinions there. But if you went back to the smaller layers, like the typography layers, and started to construct your own layout, maybe you could have some success. But you'd probably still be like, "Oh, this doesn't feel as flexible as something like Tailwind." And it's not meant to be as flexible as Tailwind or as Bootstrap. It is meant to be opinionated to the products that we're building at Shopify.

Noel Minchow:
Gotcha. Gotcha, very cool. That makes sense. Yeah, and maybe then the next question from there is we talked about some higher level layout components and lower stuff, there's buttons and drop downs and stuff. But maybe a good question to answer is how does a design system differ from something like a component library?

Alex Page:
Oof. It's a really good question. The reason why I made that sound is I think at times, Polaris feels like a component library. And the reason that I say that is a system, to me, should be really easy to change and to configure and to push out a change, and then you see that flow through the whole system. But due to our lack of coverage and due to the way that things are being architected, it makes it really difficult to make changes like that. So when I think of a design system, I'm thinking of a really low layer API of tokens. And design tokens are the smallest piece that you can have, like a blue color for links or a rounded circle for avatars and keeping that rounded circle value and then reusing that somewhere else with an icon component. That becomes a really powerful system.

Alex Page:
And then if you wanted to update that, maybe you wanted to change the font family from a system font to a branded font, you'd do that in one location instead of over 30 components. So when I think of a component library, I don't see that connection to a lower level system. It's more just like, "Here's the text, here's the page, here's the button." But if you wanted to make a change to the typography in all those three places, you'd make it in those three places. Whereas the system is providing the integral links. I think the other thing that I'd talk about is the people and the culture and the things that we're trying to impact, and they feel quite different. But maybe, Yuraima, you can speak to that? I feel like you know where I'm going.

Yuraima Estevez:
Yeah, totally. I totally felt that noise that you made, Alex, because I feel like that is a question that I have tried to answer many times and have been asked many times. And everything that you said about the system layer is completely true, but there's also this other aspect of the culture around a design system and the culture around what you're trying to accomplish with the design system. There's the aspect obviously of consistency and high quality UX, getting a lot of the free things out of the box like accessibility, performance, secure components, things like that. But without the other parts of that, it is really just either a style guide which is telling you how should something look, or a component library which is basically just building blocks that you can configure in any way.

Yuraima Estevez:
But without the two things meeting in the middle, which is where the people come in and making sure that you're speaking the same language across designers and developers, making sure that you have documented decisions about why you build something this certain way or design something a certain way or how you are recommending someone use or build a page or something like that, it all just falls into the ether and anyone can do anything, and then it is not as powerful or robust as it could be. So a design system is what it provides to you. It provides the how should this look? How does this work? Here are the pieces. But it's also the why behind it. Why is this the way it is? Why should I build this in this specific way? Why did I choose these colors, this typography, this spacing? And I think a lot of that is where the power of the design system really comes together and you get the value of it.

Noel Minchow:
Gotcha. Yeah, yeah. That makes sense. I think in my head, a design system is like a higher level [inaudible 00:17:39] there's a human element to it and there's designers and opinions and ways in which this thing should feel to interact with. But it's interesting to hear your guys' take on the community around it being so integral to making something feel like a design system versus just a component library that is maybe implementing a design system. Yeah, but very cool. I guess on that note then, can we get into Polaris and its opinions and why it is the way that it is a little bit? The visual style, the performance, that kind of thing? Maybe starting with the visual element is a good place to begin.

Alex Page:
Yeah. It might be a slightly hot take or people on our team probably wouldn't say that, but I think the visual style at times can feel a bit dated. And I will talk to the visual style though. We have lots of cards. Everywhere, you'll see in our design and in our products, are big white rectangles, lots of grays, not a lot of color. We've really tried to make the visual style feel like a powerful tool to help you complete tasks, but there's a lot of white space and there's a lot of similar or repeated patterns. And at times, it doesn't feel like that powerful tool. So back to your question though, I'll try to put a positive spin on it, there are some really great design opinions in illustration stuff, for instance, which is very flat and creative. So these beautiful aesthetics of people and masking shapes and things like this. But when you look at our design, typography, and shapes and things like this, it's a lot more rigid.

Alex Page:
It's like, "We're here to help you get things done. We don't want to really intrude or get in your way. It's a powerful tool to help you get from A to B." And at times, I don't know, that could be more creative or it could be more, I don't know, diversity of design opinion in there as well. And I think that's something that we notice is if somebody uses cards in some of the prominent areas of the website, then another person will be like, "Oh, that's the pattern that we should use in our area of the website." So that also scales some of those things where we're like, "Ah, we wish you were more creative or we wish that you tried and experimented more for design." So yeah, there's a few layers there, but yeah, we want to keep it a fresh visual style. And to make it a fresh visual style, we have to have lots of adoption. So we're really focusing on adoption right now so that we can push out more improvements to our visual style across the system, across the product. Yuraima, would there be anything you want to add?

Yuraima Estevez:
Honestly, I think you put that really well, Alex. So I'll leave it at that.

Kate Trahan:
I'm curious, there's so much, so there's a lot of documentation, the system's very big. But you mentioned it can feel old. I guess I'm curious, is there this thought that you probably see a lot of design that comes out every day. It's like, "Oh, this is so cool and awesome." How do you keep something updated and also thoroughly documented in the size that Polaris is?

Alex Page:
I don't know you can, honestly. I think that's the goal for us, honestly, as a company right now, is I think that we focus too much on scaling the system and not enough on improving the visual design. And I think it got to a point where the visual design hadn't been improved, but then the scale started to lack. So I feel like at times you have to focus on one and drop the ball on the other or focus on the other and drop the ball on the other one. And right now, it feels like we're really focusing on the scaling aspect. Our team is really focusing on getting more adoptions that we can push the design forwards. But when we get into that pushing the design forwards stages, we hope that the scale behind it is going to continue and keep its momentum.

Alex Page:
But sometimes that can drop too. And it gets into a bit of the breaking changes and how you version and how you ship large design changes as well, because that's not necessarily easy at a company of our scale. I think I read the other day that in the past 120 days, there was over a million lines of TypeScript shipped to our admin products. And that's a lot of code, and to be a design system that is supporting that speed and that momentum is really challenging. And we need to have things built in the right layers so that as those million lines of code get created, hopefully 800,000 to 900,000 of those lines of code are coming from components in Polaris. And that's not always the case, but that's the goal. So I hope that makes sense, but it's a difficult question to answer.

Kate Trahan:
Yeah, yeah. No, that definitely makes sense.

Noel Minchow:
Yeah, is there a performance element at all to the decisions you guys are making, keeping things simple? Do components generally map to the HTML native types or the primitives there?

Yuraima Estevez:
We definitely have a really good baseline that are probably analogous with, I'm going to say most or a lot of the out of the box HTML elements that exist. But we also think about accessibility. So we think about what are the UI patterns or UI components that are really prevalent in the admin, and how can we construct them and put them together so that they are fully accessible and performant? And they may not be the exact copy paste from an HTML element, but they are constructed in a way that they will hopefully work for the most people and be fast and be secure and do the job the way that we need it to do the job.

Alex Page:
Yeah. Performance is tricky. I feel like [inaudible 00:24:04] one of star designers on our team, he would even talk about the human aspect of performance and what does it feel like and what does it mean to feel like this thing is a performant product? And I think that almost comes back to UI patterns too. When I open this page, what do I see? How does it transition to a complete state? What is changing? Are things jumping up and moving everywhere or are they staying in one place? And the important information is available to me immediately and the less important information populates at a later time? So there's also that aspect, which is very difficult to systemize, but we do have patterns in our system to help with that. But then I just also wanted to add to what Yuraima was saying.

Alex Page:
There's also the lowest layer where we'll look at a line of CSS and we'll be like, "Is this will-change property positively impacting the code, or is it negatively impacting the code? And maybe this will-change property as in a button component, which is rendered 30 times on the page or something like this. And we're realizing that calling that will change too many times and we need to remove it. So there are lots of layers that we look into on performance, but I think to Yuraima's point, we've really focused on that helping users performantly flow through tasks and building the right patterns that are accessible and help them complete the problems that are put in front of them.

Noel Minchow:
That's interesting. Yeah, I hadn't considered a design system or even a component library's role in trying to reduce things content jumping around on the page and jitter and stuff like that. How are those problems solvable at the design system level?

Alex Page:
I think it's around education and also around best practices. So for instance, we don't have anything now, but we haven't experienced this section on our website and we might actually create a page there called loading. And we might talk about how to create the best loading experience. It might not necessarily have code, it might not necessarily go into depth around what is cumulative layout shift. I can't really say that word, sorry.

Kate Trahan:
Say it three times.

Alex Page:
Yeah. So we might not go into those deep, technical sides, but we definitely will talk about the impact of things moving for a user or what it means to make a page that feels performant and feels fast. A page that loads in a second from start to finish might actually feel really quick to a user if certain things populate quicker or certain things flow in. So we want to educate and inspire and also help the product designers at Shopify and the external people that use the product as well.

Noel Minchow:
Gotcha, gotcha. Yeah, that makes sense. How about you guys have mentioned accessibility a couple of times. What role does that play in your decision making? I'm thinking of things like colors and animations and stuff like that. How do those two play into that accessibility angle?

Yuraima Estevez:
Yeah. I'd actually say that accessibility is one of those core principles that we have on the team, and certainly at the design system level. I want to say everything, but that feels very definitive, almost everything that we build, we want to make sure that this is going to reach and work for the most people. So we do a lot of keyboard navigation testing. I know that a lot of the developers are testing things with screen readers and making sure, "How is this going to sound to someone who may not be able to see the screen or who isn't able to use a mouse or any other sort of ranges of abilities or disabilities?"

Yuraima Estevez:
And that does definitely come into play for color and how things scale, and even for things like what Alex was just talking about, how a page loads and making sure that things don't jump around on the page. That in and of itself is accessibility. It's, of course, something that speaks to performance and seeing what does the user feel when it comes to how fast this is? But it's also will a user who is maybe motion sensitive, are they going to be triggered or get sick because a lot of elements on the page are moving around a bunch? So we do definitely think about it at many layers, and it's something that we keep pretty high on the list of priorities.

Noel Minchow:
Yeah, nice. That's interesting. I guess I'm thinking of my experience writing React components, and I feel like a lot of the time the safety net that's helping me ensure that I'm writing HTML that is at least reasonably accessible and works for as many people as possible is linter rules will be like, "Oh, ensure there's always these certain tags on these elements so they're navigable by a screen reader. Or certain handlers shouldn't be put on this element because there's no way for someone not using a mouse to interact that way." Does the design system have those opinions or how is that enforced?

Alex Page:
Yeah, it's a really good question. One that comes to mind is a text input component in Polaris today has the label property. And the label property, I'm pretty sure, is required. So we always expect there to be a label with a text input. The problem is then we also add a property to hide the label, and this keeps scaling from there. And one of the things that I think I'd like to see with our system is a little bit more trust. And it's difficult because accessibility isn't something we want to compromise on, but we really want to give trust back to the designers and developers building these things. So one example of this might be we have text templates that don't have lay labels, and that's okay. But we trust that these teams will add the label and do it correctly.

Alex Page:
Or maybe we will, to your point, add some linting rules to double check that if there isn't a label prop, that there is still a label connected to that React element. So there's lots of approaches, and I think our current approach does feel very leaning in the side of, "We want to enforce and ensure accessibility." But at times, we might have a really complex almost table with text inputs in it to modify each row of the table, and that becomes really difficult to, I'd say, scale or make accessible when that flexibility isn't there. So there's a lot of combinations like that we're constantly thinking about in terms of what is the right opinion to have at the system level to make this accessible and how much trust and education do we potentially have to remove restrictions, if that makes sense. And that's a difficult balance to achieve.

Noel Minchow:
Yeah. Yeah, that makes sense. I think that's why I've found the linting rules are kind of an elegant solution, right? Because like, "Oh, warn me, tell me." I can go add an ignore if I know it's fine in this case. But it's a handy reminder.

Alex Page:
Yeah.

Noel Minchow:
I guess on that front, correct me if I'm wrong, but there's a way you can get a lot of the styling and stuff of the design system just with CSS includes. Is that right?

Alex Page:
Yeah, I'll talk to that quickly. We take a lot of the Sass files from Polaris and we'll run that through a build process and we can output CSS. This isn't pretty or very well documented, but what it does mean is teams that are just building scrappy or hacky and just want to use some of those CSS classes, they can do that. I think we want to refine or make this approach a lot better though, because right now it just doesn't really feel like a really well constructed or really robust solution. It's more just like a, "Hey, we can make our system more tech agnostic by running some Sass through a build process and outputting the stuff so that people can use it."

Noel Minchow:
Gotcha. Is there not a lot of components or elements that are losing structural data when you try to do that, that makes that difficult? I'm thinking like a card, I think you said there was a lot of card-esque elements. Are those not really portrayed in the CSS at all, you got to be using the React components to get those card layouts?

Alex Page:
No, you can definitely like get a dumped Polaris-Card class out from the outputted Sass, but there isn't really any documentation or explanation that, "Oh, you need a div with this thing and then inside it, you probably should add a title with this thing." So it's more around, "You get this big blob of CSS, and we really that you understand how the HTML is structured." And I think that could definitely be iterated on or be made a much better experience. But Yuraima, do you want to maybe talk about, I don't know, tech agnostic, why that's important or what that means for our third party developers? Because obviously React is great, but it has some limitations for them.

Yuraima Estevez:
Yeah, totally. So I think we mentioned, or if we haven't mentioned, so the Polaris design system is built as a React UI library. And obviously, as soon as you choose any front-end library, you're setting yourself in stone of, "This is the direction we're going. We have these opinions and we hope everybody else is along for the ride. Because if you're not, then we're going to try to give you some tools like outputting just plain CSS that you can pull in and figure it out yourselves. But beyond that, there's not much else." So because we have this third party audience who are external to Shopify, we want to make sure that those developers have the same tools, the tools that they need, and we've been talking about maybe more tech agnostic approaches, thinking about what would a world of Polaris design system look like if it wasn't tied to React?

Yuraima Estevez:
Some of that has been in the world of, "What if it was just HTML and CSS only? JavaScript, HTML, CSS? No libraries." Also, we're thinking about web components at some point, just to see, "Hey, web components are in a good place now. There's a little bit of movement behind them. They're pretty interesting. So let's take a look at what that might look like." And again, the reason that we want to do those explorations is to just push on the boundaries of what does this design look like, feel like, work like when it's not tied to React, especially in this growing world where we have more and more third party developers coming to the Shopify ecosystem and really hungry to just contribute and build apps, but not wanting to be tied to React or a very specific UI library?

Noel Minchow:
Yeah, that's tough. You mentioned even needing to bundle JavaScript files in there as well if you were to move to something more framework agnostic. What kind of logic is JavaScript handling that would need to be included?

Yuraima Estevez:
In a framework agnostic world, it would need to be any of the dynamic interactions of the UI components, I think. Really anything that's a UI component that a user can click or move or anything that you do on the web would really need to rely on JavaScript to be enabled, used? Yeah.

Alex Page:
Think of a collapsible component, which on click goes up and down and hides and shows the content, adding and removing like ARIA attributes when that happens. There's a lot of small things that we benefit from JavaScript in, especially around accessibility.

Noel Minchow:
Yeah, yeah, yeah. That makes sense. Yeah, I was just thinking of those areas that aren't handled natively, or you wouldn't just be passing JavaScript into something you imported, but there would need to be JavaScript imported as well. Yeah, that makes sense. Yeah, so I guess when you guys made the decision to use React, was that driven by just what was being used internally already and that was the logical choice, or was it just because React is so ubiquitous at this point?

Alex Page:
It's a product decision, yeah. You're right. It's, "What are we building our product with and where do we want to take our product to?" So previously, Polaris was a Rails front end library, and it was a whole bunch of Rails components, and a lot of our front ends were built in Rails. But as the company scaled and grew, it was a lot easier to hire React developers. It was a lot easier to grow teams around React that had deep front end expertise. So I don't know if that's the only reason, this is some of the reasoning that I have heard of from other people. But that was a big push to, "Okay, building React front ends is going to help us scale and build this product to be the best that it can be." Shopify is very growth driven, though. We'd love our Rails developers to learn React. We'd love our React developers to learn Rails as well. So what I'm trying to say there is we're not against any frameworks or anything like this, we're just trying to find what the right solution is for us as a company to be successful.

Noel Minchow:
Yeah, totally. I think that makes a lot of sense. That leads me to another interesting question. So say there's teams out there, they're outgrowing this, they're in house rules and they're deciding maybe they want to start building with a design system or leaning on one to do a lot of that groundwork for them, set the foundation. Would you recommend Polaris to anyone? Obviously if you're doing Shopify heavy integrations and stuff like that. But beyond on that, say you're just a React shop, do you think people should be looking at Polaris? Say if you're not a React shop, do you think it's worth checking out right now?

Alex Page:
I could try answering. I'd love to hear Yuraima's opinion as well. But my honest opinion would be no, definitely not. Polaris is an opinionated design system built for commerce, admin experiences. So what I think you would notice is maybe you'd get a really quick initial benefit. You're like, "Wow, we've got all these components and buttons and pieces that we can build things with." Then that's fine. I guess if you need that, do that. But say in six months to a year's time, you'll be like, "Actually, our product needs to be more opinionated about this. Or we actually believe that this is a better pattern for the problem that we're trying to solve." Say you were using or creating a music player and all you had was the Polaris resource list component.

Alex Page:
You'd probably be really frustrated about how that UI is built in an opinionated way because that UI was built to hold a list of orders or a list of products, and now you're trying to make it a music player. It wasn't constructed with that opinion. But that's what I was saying. If you needed something to get started with really quickly or to learn from, I wouldn't be against that. But I would say that there are probably less opinionated systems or frameworks that might be a better starting place for you if that was the approach that you were taking. But maybe one day in the future, Polaris will be less opinionated or more flexible, and then I would step back on my words as well. But that's just how I feel today.

Yuraima Estevez:
Totally. Yeah. Big plus one, Alex. I feel if what you're trying to do is build a really great e-commerce experience within Shopify, then Polaris is 100% what you should be reaching for. Probably anything outside of that, I would be a little bit concerned. Because again, Polaris is built with the idea of, "How can we provide the best e-commerce experience for our merchants within the admin?"

Yuraima Estevez:
So there's nuances there we are looking to research and making sure we understand how our merchants are using the admin, making sure that we understand how our designers and developers are building within this ecosystem. And once you break out of that, it's just really hard to know... Well actually, it's not really hard to know. This is probably something that we can say with pretty high confidence. It's just going to fall short or it's not going to do what you need it to do, or you're going to have to do a lot of hacky things and really break out of the system to try and make it work for you. And even if you can manage that, you may not get the best experience out of that anyway.

Noel Minchow:
Gotcha. Gotcha. That leads me to an interesting question. So Shopify's obviously pretty large, but these other companies where you're growing, you're working on your components and you got pretty healthy CSS and everything, when do you think it's the right time to start thinking about your component library and your CSS and rules and stuff like that, and start imagining them, or at least working with them as a design system? Do you think it happens organically and it just ends up occurring, or is the conscious decision necessary to start applying design principles to your component libraries?

Yuraima Estevez:
I'm going to say something, and I don't know if this is going to be a hot take, but I'm just going to say it and we'll see, I feel like that is a very personal choice and it's going to be different for every single company, and how it comes about is always going to be unique. I almost feel like it's like a vibe, it's a feeling. Obviously, you'll have people that come in and they know design systems and they're like, "Yes, I want to build this design system so I'm going to, and I'm going to try to get buy in and all that." But when you're sitting with the multiple products or the multiple teams, and you're like, "Something isn't right here, what can I do? What can I reach for?" And you're like, "Okay, how do I start to consolidate all these things, get more consistency?"

Yuraima Estevez:
That is probably when there's a spark and you're like, "Design systems, that's something that I've heard about. How can I get that started?" It's one of those things that at the last company I worked at, it was something that we knew we could really benefit from, and there were start and stops multiple times, I think, over several years that I was there. And we just couldn't quite get there. At a different company, maybe it's something that you can get in one try. You have the team, the buy-in, the focus that you need to do it, and you just do it. But in other instances, it might be a longer journey to get there. It might be a longer journey to realize that you needed that tool. And hopefully, once you do realize that you need it, you get the buy-in, you get everything that you need, then it's a slightly easier road to get there. I don't know if that answers the question entirely, but would love also to hear, Alex, what your thoughts are?

Alex Page:
I would just add that it feels like it's driven from a place of frustration. So, "I'm a designer and I have seen 10 different buttons. I'm so frustrated by this. This is the button. Let everyone know that this is the button." And same thing from a developer standpoint, which is, "I've built eight different modals this year, and I don't want to do that anymore. This is how we should do modals and trying to scale that." And what I you find is at some point in your career as maybe a front end developer or a designer, you'll ship these problems or see these frustrations.

Alex Page:
And either you can band together with other people and start trying to document them or write them down. Because I think the thing when the design system starts becoming a design system isn't when you have one modal. It's when you have one modal and you give the direction and the opinion and the inspiration to others around, "This is our pattern for creating modals." So I think at some point in time, you've got to be like, "It's not me fixing this frustration in a silo. I need to educate others and inspire others to follow this approach so that we don't keep falling into the same problems." And that feels like the right sort of turning point. I don't know if I've also butchered the question. Maybe, maybe not. Yeah.

Noel Minchow:
I don't think it was a particularly concise question, so I think you guys did great. Yeah, yeah. I feel like there's a lot of devs at those small, mid companies where they're on that precipice. It's like, "Well, we've got component libraries. Is this a design system? I don't know, we probably need to formalize this more." But yeah, they're also feeling that frustration of there are seven different buttons and eight different modals that each have these... Every permutation of these four attributes is leading to a different modal component. Yeah, anyway, I've been there and I know that struggle.

Yuraima Estevez:
For me, it was like, "If I have to build another carousel, I swear. I don't know, I might just leave tech altogether and get rid of this whole programming ambitions."

Kate Trahan:
Okay, I feel like we've covered so much. We are coming up on time. I do want to ask, I was listening to, I believe it was Changelog.

Alex Page:
Yeah, JS Party.

Kate Trahan:
Yeah, JS Party. Okay, thank you. And Alex, you had talked about replacing Sass at Shopify, that was in 2019, and I'm looking at this amazing spreadsheet of the solution analysis. Can you just talk through that just briefly? I just was wanting to ask, and I'm so curious how that process went.

Alex Page:
Yeah, it's still ongoing. At that point in time, we had two branching paths. It was like, "Do we rebuild Polaris from scratch, or do we fix Polaris as it is today?" We, at that point, were just doing some research into what would it look like rebuilding Polaris from scratch and what are some of the opinions that we would want to have? And this direction that we were heading in, one of the opinions was, "What do we want to do to scale our CSS?" And one of the things that we felt was at Shopify, Sass is used a lot. We love Sass and we used it extensively, but our Sass functions and our Sass mixins and Sass variables, they're not documented anywhere. And at a company of our scale where we're writing so much code all of the time, that's really bad and that became a really big problem.

Alex Page:
And some of those things that were done in Sass were also done a long time ago before things like CSS custom properties existed, or powerful tools like PostCSS with lots of plugins that allow us to do nesting without actually needing Sass also existed. So we hit this point of, "What would a future look like without Sass?" So we did some exploration into other frameworks and other approaches. One of the things that we're really excited about is also the power of the smallest CSS value. So you see this in Tailwind, and we also see this in the talk of vanilla-extract. Lots of other things are talking about this now, but those are probably two that people have heard about most. But the idea is if you were to write 100,000 lines of CSS, maybe 10,000 of those lines are actually unique.

Alex Page:
So, "font-weight: 400," will get rep repeated, let's say 800 times in your code, but you now only define that one time and have one class name defined to that thing. And that became a really powerful motivator for a company of our scale, where we're writing so many millions of lines of code that if we could, in the end, hit this ceiling of total CSS, because every single new thing would eventually not be a new thing, it would just be another thing that's replicated from somewhere else, that would be really powerful. So that's why we got really excited about things like Tailwind and vanilla-extract, because they were tools that took traditional CSS and changed the output to be a bit more the smallest piece possible, and that could be a really powerful solution for Shopify. We haven't really progressed in using either of those frameworks, to be honest, but where we're at now is we're backing our products, trying to make our products the best that it can be.

Alex Page:
We're not trying to create a new thing, but what we have done is we've started to remove Sass functions. So one of the things we're really excited about is we're launching version 9 of Polaris very soon, and that version is going to remove our whole public Sass API, and it's going to replace them with CSS custom properties. And those CSS custom properties are going to be documented. As full disclosure, they're going to be a complete mess. This is Sass converted to CSS in the worst way possible. But the next step will be cleaning that up and making that better and making that the best API for our consumers. But we're putting it in a place where we can easily transition from one technology to the next. I don't know if we'll ever transition off Sass, but we want to be less dependent on that so that we can start to experiment with ideas like Tailwind or vanilla-extract or playing with reducing the total number of CSS. So the total bundle size of CSS, I guess, is really what I'm trying to say.

Kate Trahan:
Awesome. Well, thank you guys so much for coming on. We really appreciate it, and we will see you around.

Alex Page:
Thank you so much.

Yuraima Estevez:
Great to meet you both.

Kate Trahan:
Thanks for listening to PodRocket. You can find us at PodRocketpod on Twitter, and don't forget to subscribe, rate, and review on Apple Podcasts. Thanks.