Special Guest: Kaelig Deloumeau-Prigent.

Hey folks, I'm a super busy guy and you probably are too. You probably have a lot going on with kids going back to school, maybe some new projects at work. You've got open source stuff you're doing or a blog or a podcast or who knows what else, right? But you've got stuff going on and if you've got a lot of stuff going on, it's really hard to do the things that you need to do in order to stay healthy. And one of those things, at least for me, is eating healthy. So when I'm in the middle of a project or I just got off a call with a client or something like that, a lot of times I'm running downstairs, seeing what I can find that's easy to make in a minute or two, and then running back upstairs. And so sometimes that turns out to be popcorn or crackers or something little. Or if not that, then something that at least isn't all that healthy for me to eat. Uh, the other issue I have is that I've been eating keto for my diabetes and it really makes a major difference for me as far as my ability to feel good if I'm eating well versus eating stuff that I shouldn't eat. And so I was looking around to try and find something that would work out for me and I found these Factor meals. Now Factor is great because A, they're healthy. They actually had a keto line that I could get for my stuff and that made a major difference for me because all I had to do was pick it up, put it in the microwave for a couple of minutes and it was done. They're fresh and never frozen. They do send it to you in a cold pack. It's awesome. They also have a gourmet plus option that's cooked by chefs and it's got all the good stuff like broccolini, truffle butter, asparagus, so good. And, uh, you know, you can get lunch, you can get dinner. Uh, they have options that are high calorie, low calorie, um, protein plus meals with 30 grams or more of protein. Anyway, they've got all kinds of options. So you can round that out, you can get snacks like apple cinnamon pancakes or butter and cheddar egg bites, potato, bacon and egg, breakfast skillet. You know, obviously if I'm eating keto, I don't do all of that stuff. They have smoothies, they have shakes, they have juices. Anyway, they've got all kinds of stuff and it is all healthy and like I said, it's never frozen. So anyway, I ate them, I loved them, tasted great. And like I said, you can get them cooked. It says two minutes on the package. I found that it took it about three minutes for mine to cook, but three minutes is fast and easy and then I can get back to writing code. So if you want to go check out Factor, go check it out at factormeals. Head to factormeals.com slash JSJabber50 and use the code JSJabber50 to get 50% off. That's code JSJabber50 at factormeals.com slash JSJabber50 to get 50% off.

Hey folks, I'm a super busy guy and you probably are too. You probably have a lot going on with kids going back to school, maybe some new projects at work. You've got open source stuff you're doing or a blog or a podcast or who knows what else, right? But you've got stuff going on and if you've got a lot of stuff going on, it's really hard to do the things that you need to do in order to stay healthy. And one of those things, at least for me, is eating healthy. So when I'm in the middle of a project, or I just got off a call with a client or something like that. A lot of times I'm running downstairs, seeing what I can find that's easy to make in a minute or two, and then running back upstairs. And so sometimes that turns out to be popcorn or crackers or something little, or if not that, then something that at least isn't all that healthy for me to eat. Uh, the other issue I have is that I've been eating keto for my diabetes and it really makes a major difference for me as far as my ability to feel good if I'm eating well versus eating stuff that I shouldn't eat. And so, um, I was looking around to try and find something that would work out for me and I found these factor meals. Now factor is great because a, they're healthy. They actually had a keto, uh, line that I could get for my stuff. And that made a major difference for me because all I had to do is pick it up, put it in the microwave for a couple of minutes and it was done. Um, they're fresh and never frozen. They do send it to you in a cold pack, it's awesome. They also have a gourmet plus option that's cooked by chefs and it's got all the good stuff like broccolini, truffle butter, asparagus, so good. And you can get lunch, you can get dinner. They have options that are high calorie, low calorie, protein plus meals with 30 grams or more protein. Anyway, they've got all kinds of options. So you can round that out, you can get snacks like apple cinnamon pancakes or butter and cheddar egg bites, potato bacon and egg, breakfast skillet, you know obviously if I'm eating keto I don't do all of that stuff. They have smoothies, they have shakes, they have juices, anyway they've got all kinds of stuff and it is all healthy and like I said it's never frozen. So anyway I ate them, I loved them, tasted great and like I said you can get them cooked. It says two minutes on the package. I found that it took it about three minutes for mine to cook, but three minutes is fast and easy and then I can get back to writing code. So if you want to go check out Factor, go check it out at factormeals, head to factormeals.com slash JSJabber50 and use the code JSJabber50 to get 50% off. That's code JSJabber50 at factormeals.com slash JSJabber50 to get 50% off.

CHRIS_FERDINANDI: Hey there, welcome to the JavaScript Jabber podcast. I'm Chris Ferdinand. Chuck is out this week, so I'm filling in as host. I am joined by panelist Amy Knight.

AIMEE_KNIGHT:  Hey, hey from Nashville. 

CHRIS_FERDINANDI: Steve, is it Emmerich? I always screw up your last name, Steve. I'm so sorry. 

STEVE_EMMERICH: Emmerich. It's the dev dad from sunny Naples, Florida.

CHRIS_FERDINANDI:  Awesome. And today we have as a guest, Kaleigh, whose last name I'm not even going to try and pronounce. 

KAELIG_DELOUMEAU PRIGENT:Hi, I'm Kaleigh from Cupertino, California.

CHRIS_FERDINANDI: Awesome. And Kalec, what are we talking about on today's show?

KAELIG_DELOUMEAU PRIGENT:We're talking about design systems and developer tooling around design systems. 

CHRIS_FERDINANDI: Awesome. 

One of the things that I find that we talk a lot about at the different conferences and the different things that I'm working on is open source software and a lot of people have a lot of ideas around open source software, but we don't often think about the people who are building it and trying to maintain it. I had a friend, John, who came to me, he's been a guest on JavaScript Jabber a couple of times. He came and he actually said, Hey Chuck, I wish there was a show about sustaining open source. That really hit me where I live. So we all got together and we put together a show called Sustain Our Software. You can find it at sustainoursoftwarepodcast.com. and have conversations about how it can be sustained and how it can be maintained that we build our software on most of the software we're building is based on open source. And so it's important to us to have that maintained and have it taken care of. Come check it out. It's been really interesting to listen to the conversations that they're having from people who are working in it all the time and just hear what they have to say about it. Once again, that's at sustainoursoftwarepodcast.com.

STEVE_EMMERICH: For people who don't know who you are, can you tell us just a little bit about who you are, what you do and why this topic is interesting to you?

KAELIG_DELOUMEAU PRIGENT:I was born in the west of France. Most people listening to this podcast probably know where Normandy is. It's further west of that. I'm a self-taught web developer. I started making websites when I was young and then made it my job. In 2012, when I felt like making websites in French was a bit frustrating, I moved to the UK, ended up at the BBC, then the Guardian, and then the Financial Times. So lots of media organizations there occurrences there. Following that, I moved to the US with my dear wife and found a job at Salesforce where I worked on the Lightning Design System, which is also an open source design system. And about two years ago, I moved at Shopify to work on the Polaris design system.

STEVE_EMMERICH:  Awesome. Awesome. So is Shopify's design system something that's open source or is that just something you guys use internally?

KAELIG_DELOUMEAU PRIGENT: Yeah, correct. So we have multiple design systems, but the one people know and love is Polaris, which is you can find it at polaris.shopify.com. All of the code is hosted on GitHub. The reason why it's open source is because we have a partner community that is very invested in building applications on the Shopify platform. And we want to give them the ability to open issues, contribute to the code base, give us feature requests, and just even see how it's done so that they build trust towards the component library.

STEVE_EMMERICH: Awesome. So before we dive into all the nitty gritty details, just for anybody who's listening who might not know what a design system is, can you maybe at a high level kind of explain what that's all about?

KAELIG_DELOUMEAU PRIGENT:Absolutely. So people listening to the show probably have heard of component libraries. There's a lot of them out there, but the most well-known is Bootstrap. And it happens to be a small part of a design system. If you…  If you take it at a higher level, a design system is all of the cultural practices around design and shipping a product from what the words should be in that product to the colors, to the spacing grid system, and all the patterns, the experience patterns that your users are going to encounter. Plus a little bit of guidance on how to achieve that in code. So it's kind of a melting pot of all these things that have to do with design, development, content strategy, and yeah, general user experience stuff. 

AIMEE_KNIGHT: I feel like design systems are kind of like a big buzzword right now and I mean I see the value in them but what do you think has like caused this to be such a popular thing? Is it how we're componentizing their front ends? Is that what it is? 

KAELIG_DELOUMEAU PRIGENT:I would say a lot of it, you're right, yep, a lot of it has to do with the shift to components. Design systems existed way before that was a thing. So I would say React probably accelerated the rise of component libraries because it's so easy to think in components in React. You can extrapolate and call that a design system. And some people have a sketch UI kit with all our components or Figma UI kit or you name it. And a React component library that are somewhat in sync and they're just going to call that a design system because it's like, it's a few pieces of a design system. So it is definitely a buzzword. It's also misused by a lot of people who think, I just have a sketch file. That's my design system. I don't think I agree with that. I think you need a little bit more to that. Um, I think content strategy, for example, is a big thing that's often overlooked. And, um, yeah, it is definitely a buzzword. Yeah.

AIMEE_KNIGHT: So how much do you think of like design system falls in the realm of a front end developer versus somebody who is just more, I don't know, like I guess you would call them, I don't know. There's such a fine line between what I would call like a front end engineer, which to me is somebody who like works on the build and writes a lot of JavaScript. And then I would say more like a front end, like designer or something would, I don't know, front end developer, somebody who writes like more CSS, like. I don't know. I kind of, whenever I think of design systems, I think of more like, just like it's more of something that a designer would work on, like somebody who just writes CSS. 

KAELIG_DELOUMEAU PRIGENT:Yeah, it's a super interesting topic because the teams I've seen who are leaning too much towards one or the other discipline are typically very biased in the way they build and deliver. So if a team, if a design systems team is very on the let's say back end of JavaScript. So more like interested in webpack and the React internals and all these things. They're gonna deliver stuff that's way lower level and not necessarily very design driven. And then there's teams who are only designers and only they are struggling to build that gap between their designs and production. If you want a really successful design system, you need a bit of everyone. And they need to communicate a lot and get on the same page decide of a common language. I really like when designers and developers sit down together to think about what the API of components should be. I think that's a really fruitful type of conversation you can have. And if you only have developers or if you only have designers, that's not going to happen very well. And then the gap between the idea of a designer and what's actually in production is going to be even bigger. So that's kind of my take on this. Does that answer your question, Amy?

AIMEE_KNIGHT: Yeah, I think so. And I don't know. I guess maybe where I feel like you're going with this too is kind of like the most successful projects I've worked on. The person who's in charge of design is very well versed in UX. And that's when design and dev can work really well together. But now we're kind of deving away from design systems. So we can circle back around. 

STEVE_EMMERICH: Well, one thing that would be. interesting to explore is what the developer workflow looks like in a design system. I know you actually had that as kind of a talking point for this episode, so I'd love to hear a little bit more about your thoughts on that and what that looks like. 

KAELIG_DELOUMEAU PRIGENT:Yeah. So when you build a design system, you start off by thinking about a few common rules, the language around the design, and then you try to port it to code. And when you start porting it to code, the first few components, it works really well, everyone on the same page and as you scale, your design systems becomes this behemoth with no one really having a grasp over the entire system. Especially from the code perspective, you have so many components, so many test suites, so much stuff going on that it's impossible for just one person to have a complete architectural overview of literally every detail. And what you end up doing is that you either give up to the chaos, which hopefully doesn't happen in your design system team, but you start building a practice of kind of a DevOps practice in the design systems team, where people think a lot about tooling and how we build, not just building stuff and churning components and, but also how do we release? What is the contribution model? What is the path of an idea from the designer's brain to production and what other parts where code and automation can help. And that goes a lot with, that has a lot to do with the way your stack works, but also your versioning controls works. So if you use GitHub or GitLab or Oracle or your own deployment strategy, this all has a big impact on overall way of building stuff for your design system.

STEVE_EMMERICH: Kind of sort of related, maybe potentially a little bit not. I used to work at a company that had about four or five different products that were all under the same product suite. So if you bought into, it was like a SaaS company. And if you paid for a subscription, you got all these different products, but they were all separate products because they all came in with the exception of one of them through acquisition. It was one of those, like we have a core product, we're gonna extend it with some other stuff that we acquired from some other companies and stuff. And so with these four products that had very distinct looks and feel that they were trying to maybe kind of bring together through an internal design system with some components and some shared things, basically trying to eventually migrate everybody over to using the same patterns, even though the products were maintained by different teams. Do you have any experience working in an environment where you need to get a design system adopted by different working teams and if so, any recommendations around kind of the cultural challenges there? One of the things I found both in a past job and even in a more recent kind of project I worked on, like getting people to break from this is how we do things today to using this new tool is, I've found, much harder than the technical logistics of the system itself. It's the like the cultural change piece. I don't know if you have any experience with that. If not, tell me to shut up and we can move on. But I don't know. It's something I find really interesting because it's so hard to get people to do things sometimes. 

KAELIG_DELOUMEAU PRIGENT:So at Salesforce, we were exactly in this situation where the design system was mostly built with the lens of what was called a sales cloud and with a very specific stack. But the decision was made to only build components using HTML and CSS. So they would be portable to any stack out there. It turns out, Salesforce has a habit of acquiring companies, especially a few years back, where another week another acquisition was coming kind of thing. And they would be asked to use the design system. And thankfully, they could pretty easily with just simple CSS classes. That was a good way to evangelize the design system itself, or at least the component library. Now from a cultural perspective, it depends so much on the company itself, the politics that govern it. I would say telling developers is not hard, but telling product managers that they are going to have to prioritize that over their original roadmap is a bit of a struggle sometimes. So yeah, I don't know that's above my pay grade to convince these people. 

STEVE_EMMERICH: I guess another consideration for me is like, so is there anything, coming at this from another angle, is there anything about a design system that would make people want to use it over what they already do today? Or, you know, like when you are building out a design system, how do you ensure that it's going to work for as many folks internally as possible? You know, one of the things I've seen is kind of a resistance to this as well. You know, your design system is missing these eight things that we need for our product. How do we build those in a way that it actually integrates? It's easier for us to just go do our own thing. Like forget this, you know? Like, so how do you like that kind of thing? Like, what do you, how do you build a system that's complete, flexible for things you haven't thought of, extensible for kind of future use cases, that kind of thing.

KAELIG_DELOUMEAU PRIGENT:Yeah, so there's two parts to that question. The first one is, what are the parts of the design system that would convince someone to use it? And that's really down to the culture of the company. Most companies don't have a strong accessibility and performance and CSS culture. Most teams actually kind of are bad at these things. And so they're thankful that the design system, hopefully, if that was your case, but in the design system teams have worked on, there was definitely a culture of really good CSS architecture, performance in mind, and accessibility first. So teams adopting that new framework are extremely thankful. They see things they're not good at, and all of a sudden it's put on a golden platter for them. So they would instantly like the idea. Now, the second part of your question was more around what are the parts that are missing and how do we build something that is integrating well with this whole ecosystem. This is where the design system needs to have very flexible parts to it so that composability is possible and it's not an all or nothing. You can have some kind of team specific or product specific components that can easily be made, easily be built. And to do that, typically you are going to need things like what is the grid system? What is the color palette? What is the typography? So that you can take those little subatomic parts of your design system and take them out, put them into your own components. And the, this idea of having subatomic part of your design system, again, colors, spacing, typography, et cetera. These are called design tokens. This is a name that was coined by Salesforce by Gina and John. who worked on the Lightning Design System. And it's been growing as an idea just because of what you were mentioning so that people don't have an all or nothing situation. They can take just the bits of the design system that's interesting to them and then build the components that are missing more easily. 

STEVE_EMMERICH: Awesome. And I'm sorry for just kind of like rapid fire throwing questions that you've found out. This is a topic that I always find really interesting. One of the other things that kind of comes to mind is, and this is maybe a little into the weeds, but like the installation and upgrade process. So you've got a design system, you discover an accessibility issue or a bug. How do you make sure that all the people who are using that, you know, like you issue a fix, like is there some sort of, what are some best practices, I guess, around kind of making sure those fixes get deployed to folks who need them, people who are using this project. Is it a CDN? Is it part of like an NPM installation process, something else, some hybrid model? 

KAELIG_DELOUMEAU PRIGENT:Semantic versioning is super useful in that case. Design systems that worked on were all deployed to NPM or Bower or some sort of package management system. And then it was up to the consumers to upgrade at their own pace. But when there's a hotfix, like a security or big really important accessibility fix. Design systems typically have, I would say, maximum, a handful, but typically it's one or two main consumers, like main code bases that are capturing the most traffic for the company. For example, at Shopify, it's our code base called Shopify, Shopify. It's our really big Ruby monolith. And then we have what we call Shopify web, which is our React layer on top of that. And so we're going to be meeting expectations with them and actually be proactive and push our fixes to them. But most other parts of the company, they just upgrade when they want. Yeah, we just count on people to do their duty to just stare and upgrade as their roadmap allows. So does that answer your question?

STEVE_EMMERICH: Yeah, yeah, it does. I'm also wondering if components help here at all? if I'm using hard-coded HTML and the markup fundamentally needs to change, that's a big system-wide change I need to make. Whereas with a component, some sort of custom component that bakes in some markup for me, that becomes a little bit less of an issue, potentially. I don't know if that's something you guys think of as you do this, or you just use components for other reasons. 

KAELIG_DELOUMEAU PRIGENT:Yes. 100 percent what you were saying. So the pros and cons of having HTML versus well, HTML and CSS versus React components or web components is that if the internals of a component change, people using the HTML version of them have to update all of their class names or even mockup structure, and that's a really tough upgrade process and that's what Salesforce was doing and now they're moving everything to web components. It's a huge company wide kind of cultural change at this point that we're looking at at Shopify as well. But at Shopify, we took the component road. And so we ship React components. And we have a fallback for people who still want to use our HTML and CSS. But this is not something we support. It's kind of a fallback. You're kind of on your own at this point. We don't even give you release notes on what class names changed or whatever. Here's a fallback. It's nice of us kind of thing to provide it. But the upgrade path is not going to be as clear as with React components, whereas at React components, it's so much better. We can even issue console logs. So we have a format for console logs that we follow that tells you this is deprecated. In the next version, we're going to remove it. In the meantime, you should replace this with that. And so the developer, in their console, they can actually see what they need to change for their code to upgrade better big major version is not going to completely break that code. 

 
This episode is sponsored by sentry.io. Recently, I came across a great tool for tracking and monitoring problems in my apps. Then I asked them if they wanted to sponsor the show and allow me to share my experience with you. Sentry provides a terrific interface for keeping track of what's going on with my app. It also tracks releases so I can tell if what I deployed makes things better or worse. They give you full stack traces and as much information as possible about the situation when the error occurred to help you track down the errors. Plus one thing I love you can customize the context provided by Sentry. So if you're looking for specific information about the request, you can provide it. It automatically scrubs passwords and secure information and you can customize the scrubbing as well. Finally, it has a user feedback system built in that you can use to get information from your users. Oh, and I also love that they support open source to the point where they actually open source Sentry if you wanna self-host it. Use the code devchat at sentry.io to get two months free on Sentry's small plan. That's code devchat at sentry.io.

 

AIMEE_KNIGHT: So I want to ask a question. This is kind of steering away again from design systems, but you said that you're moving to web components. So are you going to be using React alongside web components? Are you slowly like moving away from React completely in favor of web components? How do web components fit in? 

KAELIG_DELOUMEAU PRIGENT: So we're starting an initiative internally. It's very early days. This is not on the roadmap, like 100% sure we're moving to web components, but we want to be prepared in case we want to make that switch. And we want to see what is the opportunity that we might be missing. I would say that currently the developer workflow and the developer tooling around React is so good that it's hard for us to imagine moving to web components now. Also, there's a lot of unanswered questions with web components when it comes to accessibility or server-side rendering and state management. Yeah, it's really, really tough.

AIMEE_KNIGHT:  Because this was actually something that came up where I work and kind of sounds like a lot of the same things that y'all are experiencing and questions that y'all had are the same questions that I had. So that was interesting to me.

KAELIG_DELOUMEAU PRIGENT:Yeah, but we'd encourage design systems teams to at least keep that keep that on the back burner. And we tend to use hack days for that purpose to do a quick exploration of what would our most representative components look like if we were building them with web components in mind. Awesome, thanks. 

STEVE_EMMERICH: When you're going through the process of making this design system, what kind of tooling do you use? Like I knew you used Sketch and then CSS. Do you have like testing frameworks you recommend or anything like that, depending on the framework you want to go with? 

KAELIG_DELOUMEAU PRIGENT:Yeah, so for the developer workflow, if you're using React, I think Storybook is a really good place to build stuff. It's got hot reloading. You can see the entire list of your components. It's got really good tooling around it. So for example, you can get live accessibility check of your component. And Storybook happens to be plugging in with a lot of cloud providers to, for example, do visual regression testing between versions or between one of my favorite things is when you open a pull request in Polaris, you automatically get the deployment of that storybook that anyone looking at the pull request can click and we get automated visual regression testing as well. And I love that because it just gives us a list of, hey, these are the pixels that changed across the entire component library. It makes developers way more confident in the changes they're shipping that when they change the button, it changes exactly those other components and they didn't forget anything. So that's kind of the basics I would recommend. And aside from that, we use the classics, ESLint with a ton of custom configs so that we don't shoot ourselves in the foot when it comes to rendering methods and just random component life cycles, best practices. We also have a lot of accessibility, ESLint roles enabled. What can I think of? And other than that, we use Jest and Enzyme for testing components and internals of components. Yeah, that's kind of what I'm thinking about mostly. 

STEVE_EMMERICH: Cool, yeah, view storybook a little bit, it's pretty neat. When you go through the process of making this design system, how do you kind of start and work your way towards the actual building of the components? Like if I wanted to make one for my company, what would be the best way to start it? 

KAELIG_DELOUMEAU PRIGENT:I would say it depends if you already have set of components in your code base. If so, just install storybook, create a few stories, and there you go, you have a component library that you can show designers. And then designers will know, oh, so that's what's in production. That gives them some sort of inventory and you can have a conversation, sit down with the design team and discuss what parts should be fixed and what parts should make it from the codebase into their designs. Because sometimes there's a discrepancy, but when you don't have a design system between production and their design files, and that's kind of what this might fix to have this conversation showing them everything that's in production. A lot of design teams actually start like that. They go in the product, they take a ton of screenshots, and they look at, I mean, it's a UI inventory, basically and they go around and they look at all the inconsistencies. And typically you're going to find three, four different models, 10 different buttons, all that kind of stuff is just buried in the code and they don't have visibility on it. So giving them that visibility, if you can, is great. And the whole goal of this is to be on the same page with everyone in between UX and between engineering. And so that's kind of where I would start to have a discussion with designers. 

STEVE_EMMERICH: Sounds good. Do you think there's a role for a person to be that kind of mediation between the designer and the actual developer of the components? Or is it, should it just be like a conversation between the two of them? 

KAELIG_DELOUMEAU PRIGENT:From what I've seen, it is a role that's often taken by people who have a sense of engineering, but are also kind of designers. So either designers who code or coders who design a bit, they can talk to both parties with all the confidence that's needed to make that happen. Not everyone is lucky to have this happen in an official capacity. So you see a lot of skunkworks kind of projects that are emerging by just the fact that people are super passionate about this and just make it happen. 

STEVE_EMMERICH: How do you prioritize feature development? So Obviously, this is not like a one and done kind of thing. The product, the design system will evolve with the organization and that sort of thing. So it's just kind of from an operations perspective. How do you, you know, how do you figure out what to focus on next with the design system, how to evolve it, when to maybe even deprecate features that are no longer relevant or useful? Like, what does that process look like?

KAELIG_DELOUMEAU PRIGENT:Are you talking in terms of product features versus taking care of the design system or inside the design system

STEVE_EMMERICH: I'm thinking like, inside the design system 

KAELIG_DELOUMEAU PRIGENT:okay, gotcha 

STEVE_EMMERICH: Yeah, components from the design system itself. You know, like we didn't have accordions, but we need them now because, you know, Team X that uses this product is asking for them, or we've noticed a lot of people who use it have kind of hacked their own into it, so we should come up with something standardized, like that sort of thing. 

KAELIG_DELOUMEAU PRIGENT:Yeah, that's actually a very good indicator. If people have been hacking this together too many times, and it's maybe not accessible, repeated effort and lots of testing required and duplicated. That's not good. So obviously that's a good, a very good indicator that your team should probably think about integrating it into the design system. Let me think. 

STEVE_EMMERICH: Do you ever deprecate features? Like have you ever seen that happen in a design system where a component goes away? 

KALEIG: Yes, not components, but mostly props. Yes, or types.

STEVE_EMMERICH: What drives that? So what's behind the decision to remove something that was previously there?

KAELIG_DELOUMEAU PRIGENT:There's two things. There's one which is technologically, you want to move on from one way of doing things to another. So for example, when React came up with hooks, we decided that our roadmap should include moving everything to hooks. So we are still in the process of doing that. And we just released Polaris React v4, and it sets us up for success with hooks and the future of what React will look like. Now that meant that we had to prioritize moving all our code to hooks instead of component classes in many, many places. And that meant that we had less time to build new components or to do other things like supporting existing consumers. The other reason why you might want to do deprecation is there's just a different need. Recently, one of our dependencies changed drastically and we had to adapt to the way Shopify does things now in that realm so,

STEVE_EMMERICH: you mentioned the thing about not deprecating components. So does the design system run to any danger of kind of over bloating itself over time? I think about like you mentioned bootstrap at the very start here, you know, like bootstrap foundation, they become these like just these behemoths over time, where you're loading 30, 40 kilobytes of CSS for like a one page brochure site, or like, you know, design systems designed to work with a more robust app. Do you have that same danger, or is there something about the way those work under the hood now where, you know, there's less a chance of, or they, at the bare minimum, they're not creating more bloat, they potentially help with it. 

KAELIG_DELOUMEAU PRIGENT:Ideally, they would help with it in the sense that let's say every team in your product is building their own button. And not only they have to write the code, but they also have to write the tests and write documentation for it. And let's say you multiply this by 10. Not only that's going to add to your bundle size, but also it's going to add to your, uh, your, your test suite, which is going to take longer to run and you create more dependencies and more stuff not only for your users, but again, for you as a developer team. Let's say you have a design system now, that design system is going to take the burden away from those 10 teams to build that component. And instead you have one button, they can all use the same. Hopefully your design system is pretty well configured to take advantage of all the new webpack features or rollup or whatever you're using and when they include the button, they will only get the code in their bundle that they need. Let's say those 10 teams are using the same button. Now instead of 10 times the amount of code, they have it once. Now, let's say a team does not or a product does not use the majority of your components. They only want, let's say, the login form team. And they only need some text, some boxes, maybe some forms, obviously, a button, and they don't want to have to import all of your accordions or your carousels or whatever you have in your library. Well, again, I'm just going to go back to the way you build your Compat library. If it integrates well with Webpack, then you get tree shaking for free and people can import just the modules that they need. And yeah, that's kind of what modern JavaScript tooling is giving us. And I love that because you don't have to ship those behemoths. And again, an all or nothing situation happens where people don't want your design system because it just makes your app way slower at boot time at least. So I'm glad you brought that up because performance is super important.

STEVE_EMMERICH: Cool. 

One of the things that I have as a goal for devchat.tv is to cover technologies that are up and coming, things that we're probably going to have to deal with on a more regular basis in the future. Some of these include AI, VR, and one of them is blockchain. So I reached out to one of the experts that I knew, Gregory McCubbin, and we pulled together a few other people and we've started a podcast called Adventures in Blockchain. So if you're looking at blockchain as something that you may wanna work in, something that you're curious about learning more about, or something that you just wanna keep current on until you have the opportunity to make a career jump and go over and work in blockchain and crypto, then definitely check out Adventures in Blockchain You can find it at adventures in blockchain.io.

CHRIS_FERDINANDI: Let's move to, um, to picks Steve or Amy. Do you guys want to, one of you want to start us off? 

STEVE_EMMERICH: I can start if you want. 

CHRIS_FERDINANDI: That'd be swell Steve. 

STEVE_EMMERICH: Thanks. Yeah. So my dad pick this week is Cedar work play beds. I just got one of these for my son. It has a climbing wall and a slide. It's a bunk bed. He's gone crazy about it. He's telling all of his friends. He's wants to invite everybody over to play on this bed.

CHRIS_FERDINANDI: This looks awesome. Yeah. I kind of want one of these in my room. 

STEVE_EMMERICH: Yeah, that was my first thought. I was like, I can just get rid of my bed and get this instead. Oh, this is rad. Yeah, so he loves that. And then my other pick is gonna be Azure's container instances. I've been playing with that a little bit, trying to run Minecraft servers. So that's been pretty interesting. I'm liking it a lot. Next thing I'm gonna hit is the Azure functions, see how they differ from like AWS and stuff those are my picks. 

CHRIS_FERDINANDI: Nice. Amy? 

AIMEE_KNIGHT: Sure. So it's been a while since I've picked something from there's all these like different awesome lists. So this one is awesome actions for GitHub. And it's just a list of like a ton of different ones. So I'm going to go with that for this week. And that'll be it for me. 

CHRIS_FERDINANDI: Awesome. So on my end, I have a couple this week. The first, I should have mentioned this last week, but I just finally got a chance to watch the free meek mini documentary series on Amazon about rapper Meek Mill and his kind of in and out 10 year legal battle with prison system and probation. If you like hip hop, if you're an obnoxious social justice warrior like I am, you'll find it really interesting. If you're neither of those things, it's probably not going to be your cup of tea, but I really, really enjoyed it. The soundtrack is awesome too. If you like hip hop and you like Meeks music, then it's just, it's a really well done documentary series. On the developer front, my buddy Andrew Boorstein linked me to this really awesome article by Bastion Aljir, I'm almost certainly mispronouncing his name, called Simplicity 2 that talks about how our...Ironically, since we're talking about lots of dependencies in the design system, but how our reliance on build processes and dependencies makes maintaining the work that we do really hard, especially if you don't touch it for a little while. So if you step away from a project and then come back to it, you suddenly find that everything is broken. And the first thing you need to do before you can actually just update that little bit of CSS that you wanna change is get your designs or your build system working again. Um, and how maybe the house of cards we built around our development process isn't all sunshine and roses. Not that there aren't some benefits, but that maybe potentially the costs slightly outweigh those benefits. So people who know kind of me and my particular brand of web development won't find it at all surprising that, that, um, this article resonated with me, but, um, it really, really did. So, uh, Kayleigh, do you have any picks for us? 

KAELIG_DELOUMEAU PRIGENT:So I've got two picks. Back to what you were just mentioning, I am gonna pick Dependabot. It's a company that was just acquired by GitHub and it opened Pulse with pull requests to update your dependencies. And you can, with a GitHub action, you can auto-approve the PRs of the bot, which then knows to merge it into your code base. So your code base essentially stays up to date when it comes to dependencies. And that's lovely. And so we use it on a few projects at Shopify. And I love it because I used to be doing that manually and it's not fun. My second pick is I've been building command line tools over the years and it's never been fun. Actually, it kind of was miserable experience, especially with getting the console output to look like something. So you could use stuff like chalk and, but you always have to play with the process STD standard output and blah blah blah. And it's not fun. So the other day I was looking for how to build a command line tool that really looks nice. I stumbled upon this thing called Ink by Vadim Demedes. So I'm going to post the link in the show notes. But this made my life so much easier. And for the first time, I felt like building a command line interface was nice and pleasurable. So thank you, Vadim. 

CHRIS_FERDINANDI: Awesome. So, Kalec, thank you so much for being on the show. This was really great. If people want to learn more about you, visit some of the cool stuff you're building, where can they find you?

KAELIG_DELOUMEAU PRIGENT: Kalec on Twitter, K-A-L-I-G. And that's pretty much where I post and rant about web development, design systems, design tokens, you name it. 

CHRIS_FERDINANDI: Awesome. We'll make sure we get a link to that in the show notes for everybody. Cool. So everybody, thank you so much for listening. Steve, Amy, thanks for being on the panel this week. Kaleigh, thanks for joining us. And we'll chat with everybody again real soon. Cheers. 

KAELIG_DELOUMEAU PRIGENT:Thank you for having me. 

AIMEE_KNIGHT: Bye. 

CHRIS_FERDINANDI: See you later. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y.com to learn more.