Paul:
Hi there and welcome to PodRocket. I'm your host, Paul. And today we are very fortunate to have Sid Kshetrapal, who is the design systems engineer at GitHub. Welcome to the podcast, Sid.

Sid:
Hey, thank you. Nice to be here.

Paul:
So you're design systems engineer, and we're going to be touching upon your React Summit talk, that's coming up. What are you going to be getting into there? But before we get into the potatoes and gravy here, what is a design systems engineer for anybody listening that maybe doesn't spend a lot of time in the front end, or wants to get into that? Is that using component libraries and designing them? Or is it designing the entire repo structure? What level are we talking?

Sid:
I think all of it. So it's a pretty broad term for engineers who work in design systems. And so, I specifically focus on the component library side of it, but then we have other engineers that do some tooling, some token work, some specific implementation like reels or react or CSS. So I'd say it's a broad term. It's basically the folks who create artifacts of design systems.

Paul:
Gotcha. And so, would an artifact be something like it could be the components or it could be the supporting infrastructure that lets you quickly iterate and develop on those components? It could be both ends of the sticker here because one of those is very creative, in your face, front end, and the other one is more... I don't know, a dev experience engineer. You're almost SRE of the front end, I guess.

Sid:
Yeah. And I think right now, I'm working on both in parallel and it's fun to have also, I don't know, some experience with the tooling aspect of it because there's a lot of things you can do in the back of the front end that informs what your more creative side look like. I don't know, it's fun. It's fun to have more breadth over it.

Paul:
Would you say that a lot of companies that have a healthy front end that you visit and it's pleasurable to use and such, is that type of end product usually a symptom of somebody doing work like you in the back end, or is it only for bigger groups and those types of settings?

Sid:
That's interesting. I think the kind of work I'm doing right now with a big design system team, you usually only see them in companies with a lot of developers, so it's one way to go about it. But then, I've worked at smaller companies, which also had good amount of polish, and not the same level of structure or people contributing to it. So I guess what it comes down to is you need the right people who care about things at the right spot. If you have people who really care about design and the tiny implementations, making those decisions, then you'll get the right things. And when you have people who really care about [inaudible], doing that, you'll get that. It's when people mix and there's big teams, that's when I feel like the quality dips.

Paul:
Yeah. I guess that's just natural for human beings. You're giving this React Summit talk. For anybody listening, it's going to be called balancing flexibility and consistency in component libraries. Now you're giving a talk, so you're automatically a pro at everything we're going to be discussing today to the max because you're giving a React Summit talk. It's pretty cool. So one of the up the vein of thought of what you're going to be talking about, integrating APIs and component libraries, what's the difference between an API and component library? Because realistically component library is expressing itself through what we could refer to as an API, so where do you draw that line of distinction and what is this dance that we're talking about with those two pieces interacting?

Sid:
Right, so I guess depending on what framework or what implementation we're talking about. In this case, because it is React Summit, the API of components is the props that you use, so how do you compose them with children or if you have some boolean values, is label showing true, false, that kind of stuff. That becomes the API of your components and the dancer essentially is how strictly controlled are those props, so how strictly controlled is that API? Because that controls how tightly we can control the design of it. If you have a component... Let me give you an example, that makes it easy. If you have a button component that has four variants, and then those poles are your primary destructive, secondary, something like the common ones. And then, inside of it, if you want to put an item, you either get an item prop that is supported by the system or you can't put it.

Sid:
So that's one way of going about it. You can only put the icons re-allow as builders of the button component and they would look exactly like we want them to. That's the more strict API approach. The more flexible API approach is inside the button, the contents of the button, we don't control it as creators of the button. You control it as the consumer of the button and you can bring your own item, make it whatever size you want, give it whatever color you want. So that's the dancer where, how we want to be strict in the sense that there is a design system. There's a brand, so every company has this brand. We want it to look like it's a button interface of GitHub, but we don't really want to come in the way of people just trying to get their job and shift the product, so that the dancer.

Paul:
It's really defining closely and intentionally what that exposed landscape about the variability of those users of the components of the system, that's the API that you're referring to that you need to think through as a design system's engineer.

Sid:
Yeah. In my talk, I'll talk about the spectrum of flexibility, where you can create something super tight or you could create something super flexible. And there are component libraries that exist in both ends of those spectrum, and you have to find out for your company and your culture and the things you are trying to build. Where do you rely on this spectrum? And that is the amount of flexibility that you want to have. It's very hard, but it's rewarding to do.

Paul:
This is becoming apparently, as I'm talking, I'm seeing this is a people problem too. This is understanding how are people going to interact with your thing, and the interesting thing about this, it's not like you're throwing up a React library that millions of people will use. It's different company to company. You're with a different group of people every time, so your design approach has to be different for you to do the best job possible.

Sid:
Yep, totally. And that's where it becomes slightly more subjective because when I'm building a new component, I tend to look at other companies, whatever open design systems I can find. And I tend to look at how they do solve this problem. And a lot of times their solution might not work for you simply because you're working in a different culture. A team or a company where the design team has more control over what gets shipped and everything gets reviewed, like every pixel gets reviewed before it's shipped, that would have completely different API needs than a place which is more isolative and people can ship and irate on it and eventually get to a export. Because in those places you don't really want to come in the way. The last one is pure open source. Something like Material-UI or Chakra UI. They have no context of who is going to use their stuff, so they have to be the most flexible they can possibly be.

Paul:
When you say reviewing every pixel, can you give me an example story about what that culture was like, and what you really mean when reviewing every pixel? What did that review process look like internally?

Sid:
Yeah. I think I'm not going to name them because it sounds negative, even though it's not. It worked really nicely for them. I used to work at a company where before something gets shipped to users, a designer would sit next to you, look at every page and just open Figma on one side and your web implementation on the other side and just compare. And every place it didn't match perfectly, they would ask for those changes. So there was a back and forth between designers and developers before something got shipped.

Sid:
And in that case, the design system needs were very different because a bunch of times you would just have something... If a component from the design system already has reviews on it, a designer has approved it, has blessed it, then the developer can just use it and they know it's going to be fine because it's already approved. And especially in that case, the designers didn't want developers to have a lot of flexibility because they didn't want change something that has already been blessed by them because that opens the room for flexibility, and then errors and then things going off dime, so that was a very strict pattern there.

Paul:
They wanted to be right all the time with...

Sid:
Mm-hmm.

Paul:
Right, because it has to follow what they're going for. It also sounds like if you're designing in the smaller team where it's maybe not as... I guess we could call it the pixel by pixel approach. Your job as this design engineer is to offer iterative speed, so more designs come out quickly and a creative landscape where things can be done safely and within some boundaries within the system you're designing. And the other one, it sounds like you're more working to make sure things are done correctly, they're released predictably, bugs can be tracked, documented and found quickly. So which one of those lives in the jobs that you've worked, have you found more entertaining?

Sid:
Ooh, that's interesting. Because I think they're both coming from a good place, but the first one that you mentioned, which is you optimize the speed, but also put in the right building blocks so that people can actually have the same results. I think, especially now at GitHub, it's so big that most of the time, I have no idea what people are trying to build using the components that I've built. So I just have to go over the level of there are all the right pieces for you to combine, and then I'm trusting people that they want to do the right thing and they'll combine it in the right ways. But that's also part of it is also the culture at GitHub, which is iterative and you have to trust people that they will do the right thing. And if they don't, then they'll find out and they'll fix and there's heaps of tests to take care of it. But a lot of it comes down to just trusting other people to make the right decisions, so there's very few locks and stuff.

Paul:
And you really enjoy that process of just producing quickly. Because I know there are some engineers that love engineering. They love making something as perfect as it can be and stuff. So you're more on the creative, I really like to make things iterative and quick and with some guardrails. And I guess if you don't know the immediate customers of what you're designing, you're put in the shoes of like a Material-UI core contributer.

Sid:
Yeah. We're closer to that than to my previous job. But I think from an engineering standpoint, it's still fun because I don't know what people will try to build with it. It's a hard thing to build. I'd say open source library is harder to build than one where you control all the aspects and constraints of it. We do have some constraints in place, but a lot of times I'm trying to push myself into building those UIs that people might build, so there's a lot of guesswork, but there's a lot of intuition to it. I like that part of it, where a lot of the code I'm writing now is it has to be perfect so that people can be imperfect or more creative with it.

Paul:
Right, gotcha.

Sid:
Does that make any sense?

Paul:
Yeah, I know. It does make sense. It just sounds like such a experience heavy field. You really need to understand human behaviors about how these things are used in the wild to really be put in the type of shoes that you're in.

Sid:
To some extent, yeah. The good part is that these people also work in the same company, so if you're stuck, you can just ask them and have a call and say, "Please explain what are you trying to do."

Paul:
Right.

Sid:
That helps.

Paul:
We're on the vein of talking about your experiences and opinions here. What's one of the situations you've seen where a design system was either implemented from scratch, you helped implement it, or people started to really try to buckle down and use a design system component library and it actually ended up hurting speed and company time?

Sid:
Yeah. I think this happens all the time. Even so at my previous job at Auth0, we started the design system from scratch. And one you were in, I think half of the decisions that we've made, we regret making them. But that's how most competent libraries or design systems go, where you make some decisions with the knowledge you have at the time. And then as people use them, they start breaking your assumptions or they start extending the design system in ways you haven't thought of yet. But then, all of those are inputs back to your design system to improve it and try to cater to do those cases as well. It's a constant thing where you make something, you think it's good, you're proven wrong.

Sid:
And then, you take that input and then you make something again, which now you think is good, only to be proven wrong again in the future. So I think I've already had that once at GitHub. I've been here six months, but I made something I was really proud of it and it worked really well for the use cases we supported. But then within a couple of months, people started bending and stretching it ways that makes the API look wrong and made me realize that further on the flexible side than I had anticipated, so that's also a tricky thing to develop that muscle when you're new to the company. You basically don't know what the culture is like and [inaudible].

Paul:
What's an example... Just to dive specifics real quick, of how somebody bent and stretched the component or API that you originally designed into a place where it wasn't so good or it broke?

Sid:
Okay. I have a perfect example. And this is in my talk as well. We have a menu in which you can select labels and users, so think of a point request and you want to assign a reviewer to it. So [inaudible] you go through a thing, it basically looks like a drop down and you select something. Now we wanted this to be very strict in how it looks because there's a bunch of things. There's assignees, reviewers, milestones, tags, all of these things. And we want all of these menus to look very similar and have the same feel to them. So we created an API, which was very strict. It had an object shape to it. And then, it passed all our internal tests of what it should do. But then when people started using it, they started bumping into things where it cannot have a check box because the way somebody was using it, you cannot have an input type check box.

Sid:
It had to be an SVG, so that it's accessible. So then, we had to change it and we shipped it for everyone. It seemed to work out. But then somebody was like, "We want to add description underneath." Sometimes it can be one line, sometimes it can be multiple. And we didn't really anticipate this, so our design breaks. So what we going to do is give you like an escape path, where you can say, "Here's the whole menu, but here's my vendor item function, which everything else will work, but just the item you have full control over." And I think people call this inversion of control.

Sid:
Then there was groups and people wanted render group, so at some part of time, they basically had a shell of the component with three rendered X props on them, so you could customize the whole thing, which doesn't sound bad, but then we lost all control over it when it was fully custom. So then, any consistency that we wanted, we didn't have control over it and any accessibility features that we baked in, people opted out of them by doing render item because suddenly anything that we baked in, you had to re-implement it in your custom implementation. So that was a sign that the API was completely wrong, and then we recently rebuilt it in a more composable fashion. And now, we're back to a place where people have more flexibility, but they don't break or they don't eject our features, so it's still accessible and works pretty well.

Paul:
And you mentioned accessibility.

Sid:
Mm-hmm.

Paul:
So as the check, can you go into a little bit of detail? I'm just curious, why the SVG and checkbox thing had a discrepancy there.

Sid:
Right. So what we try to do is when you importing a menu from the library, it should already have the right semantics, it should have roll equals menu. The items in that should have roll equals menu item. If it's selection, then it can't be menu item, it should be menu item radio. And all of these super niche things about accessibility, most people don't know and most content developers don't know. We have the luxury that we have accessibility experts on the design system team as well, so anytime I don't know anything, I can collaborate with them and we bake that in the component. But there's rules around it, which might not be so obvious.

Sid:
When you have a menu item, that is the focusable element inside your menu. If you put a input inside it, that's incorrect because then the screen reader doesn't really know, should I focus on the menu item? Is the menu item radio the check markable thing, or is input type check box the check markable thing? So it creates these conflicting ideas. And initially, we allowed people to put checkbox inside it, only to realize that's not the right way to do it. And we have to implement it, a selection mechanism on that one, and that's when for visual users, we use SVG that has a check box because you want to show that something's checked without using a check box input element.

Paul:
Interesting. Devil's in the details.

Sid:
Yeah. And this is why you can also see how something like a vendor item really scares me because all of this detail gets lost.

Emily:
Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome Pod Rocket stickers, so check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right, back to the show.

Paul:
So when you're designing a component like a dropdown menu like this and there's menu items and such, is using things like a hard coded marginal offset, for example, to give a little bit of white space? How often do you hard code values versus have them dynamically just to client dot get bounding rect and nudging things around by percents and stuff? I've always been curious from... You're the pros of the pro, how do you guys do it?

Sid:
Oh, so both. Inside the menu, there's strict margins that you cannot override because we want to have a say on what the spacing looks like. But the actual position of the menu is a whole... I don't know. I recently had to test that. It's a 100 line long logic, which looks like where the button is and where to place the menu. And then, if the menu is going out of bounds of your window, then it tries to adjust it. There's preference on should it be left aligned or right aligned. And if the user wants it to be right aligned, but there's no space on the right, then it switches to the left. There's bunch of logic that I feel like it's very hard to read, but luckily there are tests around it, so it's not that scary anymore.

Paul:
That type of interaction is some of the stuff that's always amazed me. When you go use professionally designed website and your brain, it knows where all the buttons are, it knows what to expect. The menu's going to look like this. But when you use it, it can be in a bunch of different places. I'm a big Datadog user, and so I go to my server view and all these crazy menus are shrinking and contracting. And I'm like, "This is a living, breathing document. That's growing at every milliseconds." It's really wild to wrap your mind around how much Diff and Corner checking logic is really going on to make that sort of presentation possible.

Sid:
Yeah. Datadog is a good example because it's very dense as an interface, and those are usually the harder ones. With github.com, it becomes very dense in some place. The pool request page is very dense, and then when you're building something like a menu, you just have... You should look at the kind of stories I have. There's one story for each weird combination that it can come in and you're just hoping that somebody doesn't find a case, which you didn't think of, which they always do, of course.

Paul:
Of course.

Sid:
Yep.

Paul:
I'm sure the amount of ways that somebody ends up implementing it... When you first got into this job, were you amazed at how difficult it was to actually estimate and think about that human behavior of what you were designing?

Sid:
Yeah, absolutely. Because I came from a place where I was building components for a single use case. Where building a product, you know this component is only used in this one page, so you know everything about it. And just when you zoom out one level on top, where this component can be used anywhere in the product, the permutations are just exponential. It's just blowing up so much that you can just try to do your best and you can... I wouldn't say stress test the thing. Every time I'm building a new component now, I think I spend a day building the component and five, six days just poking and trying to make it fail and trying to document it the right way. So there's a lot of time that goes just making sure it's good.

Paul:
Documentation itself takes forever because it's really difficult to write something for another human that's not working on what you're working on. Because you really need to think about I'm in their shoes. Documentation takes a while. I can imagine when you're writing a whole API for thousands of components, it's a monster of a task.

Sid:
The good part is that you only have to do it one component at a time. I think what works for me is writing the documentation first because then I don't really know how will I implement it, I only know how somebody would want to use it. So I write the documentation from a point of view like, "This is how I would wish it works." And then I try to make that happen.

Paul:
Gotcha. That almost reminds me of test driven development. You define the API first and then you go implement it.

Sid:
100%.

Paul:
So when you're designing these components and you're cooking up this API, like you said, you're doing one component at a time. So once you're 20 components in, how are you remaining consistent? How are you getting the same mojo going that you had on day one? Are you working with a team of Adobe Illustrator fanatics that are like, "Listen, this is our vision. This is how it's all going to work." And then you're like, "Okay, I can take this and implement it," or are you really just driving that whole steam engine forward yourself?

Sid:
The team is big, there's 20-ish people, maybe more now, that work on just the design system. And out of that, the five of us work on just the React component library, and then we're always collaborating with the designers, with the CSS folks, with the Ruby folks, because that's the other part which is hard. The API shouldn't just align in a single library. It should also align across implementations. And I wish the spec was clear from the start, but a lot of time with making up the spec as we go, which means that consistency is like uh, we're always chasing it. It never seems like we can touch it, we can grasp it. It always feels like it's three steps ahead of us and we're chasing it. But I think some things that we've started to do recently have helped.

Sid:
We've started writing patterns of API and every time you see a case that you've already solved before that one becomes easier. And that's also true for using the component library because it makes it more predictable. You can guess the API, so if you've used the bottom component and now you're in the menu component, each menu item uses a similar API to the button that you're already used to. So then, you start guessing or you see a similar prop and you see that, "Okay, I used it this way and maybe it works the same way." That's the holy grail of it, where when you see a prop, you should be able to guess how to use it and you try it and it works. And then, you move on. If you never have to read the documentation, that's how we know we're doing a good job.

Paul:
What about the actual look of what you're making, and not just the API. Maybe you're more settled in the React side and the API and how that is all put together. But in terms of the actual design vibe of what's going on. Let's say there's a team of 10 people and they're making a little product, a SAS product, and they don't have a design engineer, but they want to design and they want to design consistently. What are your advice to them on how to follow suit with that desire?

Sid:
Yeah. I think the philosophy or the ways you would go about it are similar where you want to define rules for yourself. We did this at CodeSandBox. Before this, I used to work at CodeSandBox, very tiny team when I joined, but we wanted to have the same benefits of having a giant design system. A bunch of work that I did initially there was just sit with the designers and make these tiny building blocks where, what does our text look like? Every time we want to show a text, what is the exact color? And then, if it has to be subtle, what is the exact color of that?

Sid:
And then, you start baking these decisions in, so the next time you're creating anything which requires text, you're like, "Oh, I'm just going to pull in the text from [inaudible]." And then, we have a Figma sheet, which has all the variations. And you're always trying to sync the output from Figma into your components, so that anytime you're designing something new, you're like, "Oh, I'm just going to... This text needs to be little subtle, so I'm going to use text with the override of subtle." And that would mean the same in design and code. We've tried to do it with just two people working on this actively, and it got us a little far, not very far, I'd say, but I think that's the way to do it. You make some decisions and you start baking them in as variables so that you can reuse them, instead of trying to do it over and over.

Paul:
So you sit down with your team or your designer, you really flush out what the ground rules are, and then you try to abstract those ground rules into variables that you can interchange in your code. So realistically, what, I, correct me if I'm wrong here, but I'm picking up that I can go into Figma or wherever our components are later, tweak, adjust or whatever, and it should all propagate downstream effectively to some...

Sid:
Yes. Either all automated or with some manual intervention.

Paul:
[inaudible] Changing everything.

Sid:
Yes.

Paul:
I'm thinking in Material-UI, it's one of the best things when I used typography for everything. You use subtitle heading or whatever, and then you go to your theme, dot JS and you change it. And it's awesome when everything just works and it's there. That's a good feeling.

Sid:
Yep.

Paul:
So what do you think about people who use preexisting component libraries, the Material-UIs of the world? On your page, you have a React library that you were working on, but if you were making a website, would you immediately opt for one of those or would you try to design from scratch and say, "Okay, this is a whole new little micro SAS thing I'm making, so it's going to be a new vibe. I'm going to start from scratch."

Sid:
I think I rarely start completely from scratch. I always bring in something, and it depends. So for example, I almost never use something like Material-UI because it has a lot of opinions that I would either have to override or I have to replace and build my own things. So a lot of times I end up picking something which is more unopinionated or more unstyled. I was working on React, the one you referred to, which doesn't have a lot of opinions that fit on. And then, there's Stitches, which is like that. Oh, it's not Stitches, it's called Logic UI, which is built on Stitches.

Sid:
And there's a few libraries like that, which have very, very little design opinions. So I try to start there, and then try to customize and put my own design opinions there. But that's me, right? This is what I enjoy. I like poking around the details. If I had to build a product and get it out there for testing it with users and the design didn't matter as much, I pick something else. I'll pick somebody else's opinion, like Material UI or Chakra UI. So I don't think that there's anything wrong with either approach. I think it goes to what skills do you already have the team and what's important at your stage right now.

Paul:
But if you're consistently trying to override things in Material-UI, that's probably a telltale you should be using something different.

Sid:
Yeah, true. If you already have design opinions that you want at this stage, then don't use something that already has them. Or customize it. Material-UI has a pretty good customization layer or sit down, customize it, and then start using it.

Paul:
There are some things in Material-UI though, that are a huge pain in the ass to override. I have found in my experience. There's some shadowing and mouse pointer, either being ignored or stuff, that's just like, "Ah." It's really annoying. You have to throw in a bunch of crazy... Or in my opinion, not being a HTML person, it's the crazy CSS stuff of all the explanation point important things everywhere to actually get working what you want to work.

Sid:
No, you're right. Totally. It's like the teaming layer is always the easiest, but the moment you want to customize behaviors, then it's a whole different dinosaur. I don't think we have a nice way of customizing behaviors where, how should a cursor behave? Which direction should the menu open from? Those kind of details are very hard to do from the outside or make them configurable. I don't think we have a nice way of...

Paul:
CSS does have some support for this, but it's not inherently object oriented paradigm. So it can be difficult to scope and subclass things of behaviors and stuff, which would be cool to see. I'm sure there's something out there. There's probably something that lends itself to much heavier object oriented, like CSS. I don't know if you've ever used something like that.

Sid:
I've seen some implementations of it, but what I've walked away from them is it's way too hard to customize them. You have to know a lot to be able to get exactly what you're going for, and sometimes the time it takes to configure, you might as well build something of your own. So there's always that battle.

Paul:
And then, if you don't use a crazy object oriented library for CSS, somebody can then pick up your project in the future and have an easier time onboarding. So what's the point? I guess. So one last thing I'd love to touch on. I've watched one of your other podcasts, which was pretty entertaining for me. You had a great microphone, your voice was coming through nice and crisp. It was great. But you were talking about animations and I love animations. I think they really make a website pleasurable to use and they get... It's a weirdly opinionated topic, animations. There are people who love them and hate them and don't use them at all and use them way too much. So as a professional design systems engineer yourself, what's your take on animations and how they're currently used today, and how you use them?

Sid:
I think we grossly underuse them across the web. Very rarely do I see a website that's using them tastefully. And I think that's the hard part with animations, or motion in general, that it's very easy to go from, this is useful to give context, to this is now just whimsical and it's trying to be funny. I don't know. I'm sure there's rules and people study animations and motion, and there's constraints that you should learn. I don't know them. So I just go by my taste of what looks good.

Sid:
And I imagine a lot of people also don't study the same things, so it's very hard for us to grasp what is good. I think this happens with design as well. A lot of developers are very good at building components, but they haven't studied design in the same way that designers would have, so they have a hard time, struggling with what looks good and what doesn't. When they design something, it doesn't come off as good, even though they're trying the same. I think motion and animations are even further on that line. It can be really useful when done right, but it's rarely done right.

Paul:
Do you think that there's a tool out there, or for design, there's just [inaudible] rules, is there something similar for animation, whether it be a library or a set of practices or paradigms that you've looked at that you've found helpful?

Sid:
Yeah. Personally, for me, I've really enjoyed physics-based, spring-based animations. So for example, Framer Motion or Remotion. There's a few of them. They all use spring-based animation. And that, just that structure of thinking about your animation and how much weight would it be makes a lot more sense to me, because then I can think of how far is something animating. If it's just a switch that goes on and off, the distance is very small, so the speed of it needs to be a little slow, versus if there's an overlay that opens on the whole page, like a model or something, that's a lot of pixels that are traveling and if they travel at the same speed, it looks sluggish. They want them to be fostered and just thinking of it and weight off the component and how much speed it should travel, makes it easier for me to make something that looks decent because I don't think in seconds, how much seconds should it take, or what's the Bézier curve like? That doesn't make sense to me.

Paul:
Right, and it's funny too, because if we go back 10 years, if I animated anything you had to get in with the Bézier curves, or 15 years ago. You can still see them in the developer tools. You can look at the curves and how things are animated, but why touch that? What were the two libraries you mentioned? Framer and?

Sid:
There's Framer Motion.

Paul:
Framer Motion.

Sid:
And the other one, I want to say it's just React Motion.

Paul:
And these libraries, do they have healthy APIs that you think help orient your thinking towards how to use animations effectively?

Sid:
For me, yes.

Paul:
Okay, cool.

Sid:
There was a bit of a learning curve because we don't interact with Springs a lot, so we don't really have a sense of how much weight or how much friction is there in it. But once you get past that, it feels a lot more complex than... But you don't have to know all of it. I would say you only need to know 5% of the physics to get into the zone of what is easy to manipulate and what will give you the direction that you want.

Paul:
No Maxwell's equations?

Sid:
No Maxwell's equations, thankfully. I think there is a bit of a learning curve, but after that, it's a lot of fun.

Paul:
Nice. Framer Motion, I saw it on your other podcast and it looked really simple to use. I've used GreenSock before, which is super pleasing. Some other APIs are very rich, a little confusing, so that one just seems way easier. I'm definitely going to check that out. Damn, we're already at 40 minutes. That time flew by. To close out, Sid, is there any resources that you'd want to throw? If you have a Twitter, what's your Twitter? So our listeners can listen to you and follow you anywhere else, or any shadows you want to give?

Sid:
All right. My Twitter is siddharthkp, you just have to find it in the description below because it's hard to spell.

Paul:
Gotcha.

Sid:
And I guess that's it. Check out Primers, that's the design system that I'm working on these days. It's all open source. There's a lot of... It wouldn't make sense if you're not GitHub, but there's a lot of things that you can steal and copy and get inspired by.

Paul:
What was the name of that again?

Sid:
Primer, so primer.style is the website.

Paul:
Primer.style, great. Sid, well, thank you for your time, thank you for coming on and talking about... The candy shop and what's all behind the engineering of it, of front end and the things powering our websites.

Sid:
Thanks for having me. This was fun.

Kate:
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.