922: Pre-commit Hooks, requestAnimationFrame, Code Reviews, and More

In this potluck episode of Syntax, Wes and Scott answer your questions about code reviews, migrating legacy apps, CSS attr() use cases, pre-commit hooks, the future of creative web development, whether front-end devs need to be full-stack, and more! Show Notes 00:00 Welcome to Syntax! 00:43 When is the appropriate time to use requestAnimationFrame? 05:10 How do you handle code reviews on larger teams? 13:08 When to use the CSS attr() function 19:01 The future of browsing websites and the impact of AI 28:45 Brought to you by Sentry.io 29:10 Navigating browser preview in VS Code 31:31 Pre-populating email content with mailto 34:29 Is there increasing pressure for front-end developers to become full-stack? 43:14 What pre-commit checks should you run and how? 46:16 How do you deal with a poorly-built codebase when you already have thousands of active users? 50:05 What GitHub Copilot features should you disable while you’re learning something new? 52:22 Sick Picks + Shameless Plugs Sick Picks Scott: WOLFBOX MF100 Electric Air Duster Wes: Competition Kettlebells Shameless Plugs Syntax YouTube Channel Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. We've got a Pollock episode for you today, which is you bring the questions, we bring the answers. Keep the questions coming, folks. Go to syntax.fm. In the bar, there's a hyperlink you can click on and you can give us your question. We'll answer it in an upcoming episode. Today, we've got some really good questions on should every developer be a full-stack developer? A lot of people have frustrated that all the job postings want you to do absolutely everything. How should you review a pull request? What does that even look like? Migrating a large PHP app? What is the use of the CSS ATTR function? So it just landed in Chrome. You can use it on all the HTML elements. What is possibly the use for that? And then some VS code tricks. Some really

• 0:41Wes Bos?

  good questions today. Let's get on into it. First question we have here from Big Dave. When is the appropriate time to use RequestAnimationFrame? And does it differ in React's felt Angular? Yeah, this is a cool question. RequestAnimationFrame is a function in JavaScript that essentially allows you to queue up some work that needs to be done. And very likely that has to do with updating the DOM or something that will cause a repaint on the page. So I'll use this if I'm trying to draw something to the page, or if you're trying to use a canvas and you're trying to update the canvas as often as you want. Now, normally,

• 1:22Wes Bos?

  you would think, okay, well, I want to run this thing, like maybe some monitors are 30 frames a second, some monitors are 60 frames a second, and some monitors are 120 frames a second. And then you have to think about like computation as well, meaning that like maybe you can't run that as often as you want because it's computationally expensive, and maybe you're only going to get 20 frames out of there. So there's this like problem with the browsers, like how often do I run this updater function? And instead of having to figure any of that out, you simply just run RequestAnimationFrame, meaning that

• 2:02Wes Bos?

  you say, hey, browser, I would like to paint this. When you are next able to paint, please go ahead. And run this function to update the canvas or to rotate an item a certain amount and so on. So it's it's pretty nice because you don't really have to figure out how frequently you want to run something. You just ask the browser and it's going to figure it out for you and people that have 120 hertz displays that are running on super powerful machines are going to get as fast as possible. And other people who who may not necessarily have that refresh rate or CPU power are going to get a little bit left.

• 2:43Wes Bos?

  So the question of when is the appropriate time to use request animation frame? Essentially, any time that you want to run something as frequently as possible without having to bog down the UI and how to overload the processing in there. Does it matter between React, Felt, Angular? No, this is a lower level JavaScript API and it doesn't really matter. I did have somebody once on Twitter say that they would try to throttle their request animation frame to not run too often. And I was like, huh, interesting. But then everybody came out and be like, no, that's that's kind of a moot optimization. You know, like, I don't think you should should be really been doing that.

• 3:27Wes Bos?

  One thing I'll have to also say about request animation frame is if you're doing animation with request animation frame, you you must use the time that is passed in into it. So when you when you start an animation, request animation frame might not be called every, like, I don't know, 60 frames a second, 1000 milliseconds, every 16, it's not, might not be called every 16 milliseconds. If you're trying to to shoot for 60 frames a second. So what can happen there is sometimes you're on a website and the animations run way faster

• 4:07Wes Bos?

  or they run choppy, meaning that they're like, if you're rotating it like a degree every single time that this runs, it might run way faster or way slower or is at a choppy amount. Then you think it will. So you'll have to actually run the, based on when you started the animation and based on how far you are, given time, not amount of times that this function has run. That's how you figure out the degree that you rotate something to, or how far along the screen it is.

• 4:35Scott Tolinski?

  Yeah. Lovely explanation. Request animation frame. I remember when it showed up, one of those things that makes our lives a little bit easier.

• 4:42Wes Bos?

  Way easier. Yeah. Yeah. Just, it's good. It's good.

• 4:46Scott Tolinski?

  Yeah. I remember the first time I saw this syntax for it being like, "So what exactly? How do you do this? How do you use this?" Yeah. For some reason, it didn't like speak to me immediately. Yeah.

• 4:57Wes Bos?

  Yeah. Because the last thing you do at the end of a request animation frame is you request an animation frame again, right? And then basically you just, you call it infinitely until you have a break or exit condition.

• 5:10Scott Tolinski?

  Yeah. All right. Next one from Mike W. "Just found your show four to five months ago." Hey, welcome, Mike. Been going for a little bit. So happy to have you. "I have absolutely been loving you guys' Canadian podcast." Oh, yeah.

• 5:23Wes Bos?

  Thank you, Mike W. He's from B.C. Good.

• 5:27Scott Tolinski?

  Uh, I'm from B.C. And Scott Svelt represents CJ. Your video content is amazing. My, oddly enough, two of, two of the three of those are Rocky Mountain folks. "My question is, how do you guys handle code reviews? I've been working on larger teams recently. They aren't huge by any stretch, just larger than the one to two man show that I'm used to. I haven't really found a great groove yet to where and how to do good and meaningful code reviews. GitHub web can be super slow. I tried GitKraken and VS Code, but nothing feels right for me. Can you guys offer any alternative tool, suggestions that, or maybe just some pro tips or advice on how you do them?" Yeah. I've never used an app for

• 6:11Scott Tolinski?

  this specifically. There are other apps like Git clients, like Git, Git Tower is one that has been relatively around for a while. Now, I don't know how well this works specifically for code reviews. I just know that that's a Git client that people like, the official GitHub client as well. As far as code reviews go, your process around code reviews... I think we'll differ from person to person. I am not going to lie, my attention to detail and my just general nature has always made code reviews a bit of a challenge for me because I can look at it all, I can test it all, I can try it all, I can go through it and it all seems fine and I might miss something.

• 6:53Scott Tolinski?

  So for me, the tools, the tools, the tools, the tools have always been the biggest thing to help with some of that. If we're talking like code quality stuff, if we're talking specific code style things, like if you're, if your company has a code style that things need to adhere to, you shouldn't have to put that on to the person doing the code review to find those things. Those things should be found with a tool, whether that is like linting or any of those things. So just, just my, my standpoint there is to automate as much of that stuff as possible. And granted, you know, there are things you'll want to look for and have a good eye for. But in larger teams where people, where you're probably spending a decent amount of time

• 7:36Scott Tolinski?

  doing code reviews because right, people are shipping stuff, people are writing code, multiple people, people have different coding styles. I think your process in general is something you'll want to sit down and like really try to formalize. Now granted, I don't know if this is, you know, non-obvious advice here. Automate what you can automate, formalize your process. The app I think is less important. We've always just used, I personally just always use GitHub for this. Wes, I think you just use GitHub and CJ does as well, so.

• 8:08Wes Bos?

  I'll tell you what I use in just a sec, once you're done, because I've got some thoughts here.

• 8:12Scott Tolinski?

  Okay. Well, you give me your thoughts right now. Let's, let's have a time lab.

• 8:16Wes Bos?

  All right. Let me share my screen here. I use GitHub Pull Requests. It's a VS Code extension.

• 8:24Scott Tolinski?

  So you use that for code reviews, okay?

• 8:26Wes Bos?

  Yeah, so what I'll do is I'll open up the GitHub Pull Request extension and it will list all of your open pull requests. So here is an absolute monster of a pull request that I've put in to convert every single MP3 URL from our old host to our new host. And I asked in the chat if anybody would help me review it, just to like, obviously you can't go through every single one or you can write a script, but just to give it a quick look over. Nobody so far has helped me out. So, dear listener, I have the same problems as you. My poor teammates are not reviewing my code.

• 9:00Scott Tolinski?

  I was on vacation, by the way. Actually, I wasn't on vacation. I was on a work trip.

• 9:04Wes Bos?

  That's fine.

• 9:04Scott Tolinski?

  Yes, I was on a work trip.

• 9:05Wes Bos?

  I'll allow it. But basically, my process is like this, right? So I'll open up the pull requests and you just basically go through each of the changes. And as you're done, you can go ahead and check them off as seen. You can also add a little comment on it being like this, "Sucks," you know? And I feel like this is a much more comfortable UI, because this is also where I'm writing my code, right? I can make edits to the code myself. I can leave comments on it. I can do suggestions. I can start a review. I think this, it's a totally separate extension from the like Source Control, the Git integration in VS Code. It's an actual extension from GitHub called GitHub Pull Requests.

• 9:50Wes Bos?

  And I think it's highly underutilized. I've been trying to force myself into the like, out of the terminal into like a GUI, because everybody says, "No, you gotta use a GUI for this type of stuff." And this is the first thing that's stuck, which is the process of

• 10:07Scott Tolinski?

  Checking.

• 10:07Wes Bos?

  reviewing pull requests, yeah.

• 10:09Scott Tolinski?

  Yeah. Yeah, my biggest problem is that like when people submit pull requests with a lot of code. To me, I can get bogged down. Like markdown, sure, or small changes, functions, whatever.

• 10:21Wes Bos?

  Minus 900 files.

• 10:23Scott Tolinski?

  Right. But it's markdown. You're not like getting into it. But when there's like a big old pull request of several components and large files and all sorts of stuff, I can definitely get bogged down in a little bit of like my eyes glossing over and it looks good to me type of thing. So I think it helps to be the type of person who has a really good attention to detail for these types of things. And maybe that's just not me. I think that takes a specific type of brain.

• 10:52Wes Bos?

  Yeah. One more tip there is you can also stack pull requests. So when you're implementing a feature, often what will happen is you'll think, ah, well, while I'm here, I might as well do this. Or in order to implement this, I need to change how this other feature works, you know? And if you throw in a pull request that has the fix for what you want, the change of how something works, and the like, well, I'm here, I might as well go ahead and update the packages and whatnot, then it becomes just like this, like, oh, this is too much, you know? And like, ideally, yeah, you put in like three separate pull requests for those types of things. But what you really want to do is is stack them, meaning that you maybe

• 11:35Wes Bos?

  update your dependencies first, open up a pull request for that, but then continue your work on, branch off of that work already.

• 11:43Scott Tolinski?

  Yep.

• 11:43Wes Bos?

  And then you have a second pull request that does the changing how things work, and then a third pull request, which is actually implementing it. And that way, when they're stacked, they're a little bit easier to review. One thing doesn't necessarily break another. And then they're a little easier to view and you can you can merge them all in at once, or you can go through them one by one. They're a little bit more manageable that way.

• 12:05Scott Tolinski?

  Yeah. Yeah, I like I like that. And that is a I think that's a problem that can be solved with just like proper education in teams and like not accepting poll requests that because like if you put like so if your if your employee comes to you and is like here's this poll request with that right the quick fix this and this and that all in one and you say I'm not going to merge this please bring these as separate poll requests the amount of like effort now that that puts on that developer to go and fix that if somebody tasked me with that effort I would be like I ain't doing this again I'm going to do it the right way next time because that's such a a pain now to split that stuff out so yeah

• 12:47Wes Bos?

  I think this is also a spot that AI will help us significantly because this is just often it's just grunt work and you're gonna miss things you know if if you're relying on somebody just kind of scanning it and running the tests and whatnot AI is much better at those monotonous things and possibly catching things that you should then review

• 13:07Scott Tolinski?

  yeah totally

• 13:08Wes Bos?

  Mike asks could you give me some realistic examples of when to use the CSS ATR function and when that might be useful why would a CSS value end up in HTML and HTML's data attribute is there a real world use case for that so he's talking about in CSS now we're able to use ATR to be able to access your HTML attributes and that's really exciting we've been able to do in like before and after pseudo elements which was handy for like tool tips and whatnot but now you're able to actually access all of the HTML elements attributes

• 13:47Scott Tolinski?

  in Chrome

• 13:48Wes Bos?

  is it all of them yeah it's just in Chrome is it just data attributes or

• 13:53Scott Tolinski?

  I think it's just data attributes I think it's just data attributes let's see

• 13:57Wes Bos?

  let's double check that nope no it is it works

• 14:02Scott Tolinski?

  oh yeah non-string values

• 14:03Wes Bos?

  href href as well and that's that's really handy because you often want to grab the href the title the alt the maybe oh I don't it doesn't work with value because

• 14:16Wes Bos?

  Well, you can get value, but it's not updated. Like if you, if you have like an input type of range.

• 14:22Scott Tolinski?

  You couldn't do like dynamic.

• 14:24Wes Bos?

  Yeah, and if the, if the value will be whatever is set as default, but as you, you scroll it around and change it in JavaScript or in the DOM, it's not reflected, which maybe that will change. That's, that's kind of a cool use case. But let's talk about the, the real killer feature here. The real killer feature here is declarative UIs, meaning that in order to make your HTML as declarative as possible, you can pass in settings, colors, counts, anything as data attributes or just regular attributes in your HTML. And that's really cool because then you don't have to write some JavaScript to pass those values in.

• 15:07Wes Bos?

  And you, you don't have to pass them in kind of a weird way, which is using inline style attributes. You can simply just put a attribute on your, your HTML element, which is, you could pass like color.

• 15:22Scott Tolinski?

  Yeah.

• 15:22Wes Bos?

  You could count, like how many items should this be? How many columns? Like imagine a declarative CSS grid. It's such a common thing. I just want a box with three columns in it. And you, you can have like a, you can, you can throw a class of grid on it, or you can simply just do data grid calls equals three. And boom, it'll, it'll give you three because you can access those values from your CSS. So those are probably the most killer features of just accessing settings. The other one is probably like tooltips, being able to access the, the URL, the, the title, the alt text of an actual element.

• 16:06Scott Tolinski?

  Yeah, some people, I have an example where people are doing like citing sources and that kind of stuff. I do think there, once this works well with the upcoming if statements, once it works well with style queries where you can query off of attribute values, what you're essentially doing is adding the features of styled components into CSS. Because you're essentially able to pass values into your CSS and then conditionally show or modify CSS with the attribute value. So that is essentially in CSS and JS, when we pass a prop into a styled component and

• 16:51Scott Tolinski?

  then do an if statement in JavaScript inside of our CSS, this is getting very close to that with just straight up CSS. And to me, that seems really, really great. A lot of the things that, like you had mentioned, can be done with classes, but at the end of the day, one of the things that we've been doing for a long time is abusing classes by just adding classes, removing classes, a whole bunch of them, left and right. And you're kind of polluting the class thing, and I think most of us have gotten into a situation where we have like button, danger button, button this, button large, or whatever. You have all these different additional classes that could make more sense to be like props,

• 17:32Scott Tolinski?

  which attributes can be seen as kind of like props and styled based on that, rather than adding and removing another class here and there. And I think this makes it all a lot cleaner, in my mind.

• 17:43Wes Bos?

  And it wasn't even even just adding more classes, but like the way that you do this now is you you pop like a style attribute on the element, and you say style equals, and then inside of that, you can you can do like dash dash speed colon 300, you know? And that syntax kind of sucks because you're just dumping a big string in there. It's a little bit better in like React world or any of these framework worlds because you can pass like an object which is style. But like, I even imagine this is going to be killer for Tailwind, because for Tailwind to be able to specify both like a property...

• 18:26Wes Bos?

  And a value in a go is going to be great. Imagine you could do like, like group equals card on an, on an actual element and then you can access that in other spots of your CSS. And then also with not passing the inline CSS is you're not having like weird specificity issues where you're battling each other with the, with it because now you have some inline CSS and so now you have some that is written in your actual CSS. Everything is just in your CSS file and you can access the data attributes or your regular HTML attributes from there.

• 19:01Scott Tolinski?

  Word. All right. Next question from Luke Ruokaismaki. Ruoskaismaki. I hope that was right, Luke. Sorry. As somebody who has a long key ski last name, I get it. Less a question and more a general comment. In episode 911, you mentioned Brave browser briefly. I'm a Brave user and one of the main reasons that I appreciate that someone is trying to find a solution to the ad problem. Like most, I always run an ad blocker, but I'm aware that this hurts sites and companies' income, mostly because they'll tell you obnoxious pop-ups telling you disable the ad block. Yes. I don't know that Brave solution with BAT. What is that? A basic access token?

• 19:44Wes Bos?

  No, basic attention token. So their whole idea is that like, you can like put money into your Brave and then based on like content you are consuming, some of that, those tokens will go to the actual authors, which I was kind of excited about as somebody who writes blog posts and posts videos online in the early days.

• 20:05Scott Tolinski?

  I have a decent amount of basic attention token because of YouTube. In the past, I had connected level up tutorials properties to that. And because of that, I was getting a ton of it. The only problem with basic attention token is that it's worth less than dirt. So it's like...

• 20:27Scott Tolinski?

  If we're talking about like actual ad dollars or anything like that, Yeah. Not very much. So, okay, I don't know that Brave's solution with BAT will be the solution, or if there's some other integration, but I don't know if there's any problem, a significant attempt to solve this problem. Which leads to the actual question, with more people doing research, or just in general, reading and planning with AI tools, it seems like there's less of a need to actually visit sites, since the tools can either find, ingest, and summarize the site for you, or can take a link to a website and summarize, etc. Do you have any thoughts on if this will become the way most people interact with the browser on the internet, and what would this do for people or companies that rely

• 21:12Scott Tolinski?

  on ad revenue? Keep up the awesome work. Peace from Australia. This is a great question, because I think this is a big topic. I had a lot of conversations about this topic when I was in Amsterdam. And from Tejas Talk, he did a talk on Langflow, but a big portion of his talk was about how UIs are great, but everybody brings their own UI to the table. You gotta hunt for things, you gotta do all the stuff. And ultimately, the reason why people are going to chatbots is because it gets them an answer faster than going to the UI. And I love UIs, I'm a UI person. But like, what if the UI and the chatbot merge in a way where you can have new UIs

• 21:56Scott Tolinski?

  that bring you the information from a faster and easier way, that's more reliable, and maybe more how you're used to accepting it? Now, I love creative UIs, I love creativity, I like art, I like all that stuff. So that's like a big portion of it. Like, how many people are going to replace their general browsing of actual sites? And think about it this way, the first consolidation happened where we used to have web rings, we used to have individual sites, we used to have creative applications on the web, and all those filtered into what? Social media. And in social media, you got the few sites that you visit all the time. You got Instagram, you got Twitter, you got Facebook, whatever.

• 22:38Scott Tolinski?

  These social media sites took up a lot of that personal space that was somebody's own personal space on the web. The personal space is now group spaces. And then so that shift to that changed a lot of that landscape as well in terms of the UIs that we're using. And I do think that this chatbot revolution that we're seeing right now, normal ass people using chatbots to get information all the time, I think we're going to continue to see that change into the point where browsers are going to become that interface, the browser itself. This is something that has been really highlighted to me since moving to DIA as my full-time browser.

• 23:23Scott Tolinski?

  DIA, their search bar is essentially a chat window. It's a chat window that you can ask about other tabs. It's a chat window that you can summarize multiple tabs. It's a chat window that you can go and get access or summarize YouTube videos or whatever, and it is deeply integrated into the browser. I think the next big shift in future UIs is going to be the UI of how we browse the web through a browser and most likely what nobody's really doing right now on the dang phone. Like, I gotta ask myself 100 times a day, why is DIA a web browser for the computer

• 24:04Scott Tolinski?

  when most people are using chatbots on their phone and browsing the internet on their phone? Where is the DIA on the phone that is doing those things that's taking that space? So if I had to imagine it, I would imagine future UIs are going to be pulling in UIs from the browser rather than you going out to a website. You're pulling in UIs that give you the stuff that you need. Now, I mean, who really knows about any of this stuff? But I do think that is going to be a shift, and that's going to be a massive bummer for those of us who like the creative web. And I think the creative web will still be there, but like, general ass people...

• 24:43Scott Tolinski?

  They're going to be utilizing their browser as essentially the window to pulling in information rather than having to go and visit sites.

• 24:53Wes Bos?

  I've been thinking about this question a lot. Like, we saw it with newspapers, right? There's a lot of people who used to do really good research and newspapers used to pay people really good money to be reporters. And as that space kind of phased out, we don't see it as much anymore. And now I think about that with the web as well, because like, I write blog posts, I write content, I put a lot of content out there. And that content is, yes, it's consumed. We put a lot of content that's consumed by people, but a lot of it has been used to train these AIs and for people to just get a very quick answer. You can see the amount of like bots visiting websites is going up significantly because

• 25:38Wes Bos?

  you ask a question about JavaScript and it's like, whoa, let me just go suck in 40 pages of that talk about using JavaScript cons variables and then just distill it down. And from a user point of view, I frickin' love it. I don't want to spend half an hour reading through your life story about X, Y, and Z. I just want to get straight to the actual answer of what it is that I'm looking at. We saw it with Google summaries as well. You Google something. How often do you like Google something and just read the summary and close the tab because you have your actual answer, right? So for those people who do it for money, where those businesses are going to be significantly disrupted.

• 26:18Scott Tolinski?

  Yes.

• 26:19Wes Bos?

  And then like, what happens to people who rely on that money in order to put information out on the internet?

• 26:25Scott Tolinski?

  Right.

• 26:25Wes Bos?

  I don't, I don't know. But it's a tricky thing because I'll tell you, there's no shortage of people putting information on the internet right now. There's no shortage of people just sharing what they know. And will that stop at a certain point? I don't know. I hope it means the end of the like awful clickbait, here are 14 things you must see in Italy when you visit. You know, like all those like awful websites that have popped up over the last five, 10 years where it's just like garbage SEO content. I hope it means it's the end of that. But unfortunately, I also think it's going to be the end of

• 27:06Wes Bos?

  people putting out very helpful information. You know who I want to get their thought on this?

• 27:13Wes Bos?

  And who I think that got, got, I don't know if they got out in the right time. Chris Coier, I'm curious, his thoughts on this. He spent a good chunk of his life, his entire legacy was putting, or his entire legacy is putting out very helpful information on web development on the web. And the CSS tricks was such a huge swath of information.

• 27:37Scott Tolinski?

  Changed my life.

• 27:38Wes Bos?

  For so many people to learn, absolutely life-changing. And he was only able to do that because he was able to make money on it as well. And imagine, like, is the next CSS tricks is not going to make that much money. He's not going to be able to dedicate those, those resources to it. So I'm very curious to hear what his thoughts are on creating and writing and content and information and putting it out there when

• 28:04Scott Tolinski?

  Yeah.

• 28:05Wes Bos?

  the, the upside to it is, is, is much smaller. It's just these AIs are going to gobble it up and, and short-form it for your, our, our brain-rotting people right now.

• 28:18Scott Tolinski?

  Yep. Yeah, I know. It's all, it's all, we're in a weird world.

• 28:23Wes Bos?

  I don't, like, I don't think it's necessarily a bad, and I think there are, are things that we have not yet figured out. I, I think that we will likely adapt and, and see how these things work. There will be some bad things, and there will probably be, be some good stuff that comes out of it as well.

• 28:38Scott Tolinski?

  And there'll probably be some things we don't see coming.

• 28:41Wes Bos?

  There's, for sure, a lot of things.

• 28:43Scott Tolinski?

  Things work. Yeah.

• 28:44Wes Bos?

  Yeah.

• 28:45Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/syntax. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 29:10Wes Bos?

  Jeff says, "While developing, I want something that will navigate browser preview to the corresponding output file of the currently focused editor file I'm working in VS Code. I have searched the internet for four hours and I was sure you have mentioned an extension or something. I can't seem to do the one that it is." And then he goes on to explain it. "Yes, I have this exact problem as well and I built a solution for it. If you go to github.com/westboss/hot-tips and you look at my vite config, when I start the vite config, it just takes a listing of all of the files and then it finds the most recently edited HTML file and will automatically open that up in the

• 29:55Wes Bos?

  browser for you." Because I'm sure you could take that and extend it to simply just show the one that I am currently working on right now, or some little browser shortcut, but that's the exact problem that I have of I want to open the most recently edited file. And I also, similarly, I made another extension called vite Directory Contents. I think you can just run npm viteer and it will fire up just a regular vite process, but it will also make a directory of all of your files. Because in my tutorials, you can't tell people to directly type in the name of the HTML file that you want to go to. It's so much nicer when you can just see a list of files, click on the one you want, and then it renders out.

• 30:41Scott Tolinski?

  Yeah. It's tough too in a component-based flow, you know, like how many times you're at the root page and how many times is that, you know, like you have slugged pages or something like that, like where do you actually go in those instances? So there are so many times when that wouldn't work. It would like mostly just work in your specific use case that you mentioned.

• 30:59Wes Bos?

  Just HTML, very simple.

• 31:01Scott Tolinski?

  Yeah. It's one of those things that I think on the surface, it seems like a good idea, but then when you get into the edges, you're like, oh, this actually wouldn't work at all.

• 31:09Wes Bos?

  And the other way around as well is when you're visiting a page, you often want to know, A, where is this content in the database? And B, if you're like using a CMS, and B, what components are currently on the page? Like, what do I need to edit to be able to do that? And some frameworks are better at that than than others.

• 31:31Scott Tolinski?

  Yeah, totally. Word. All right, next question from Ben Jackson. I just had an idea for a website contact form that I don't think I've seen before, and I wondered what your thoughts on it are. Normally, I would use an external service, possibly Forms, Pretty, Resend, Netlify Forms, whatever, but I just had the thought that it could be done using a simple mail to anchor href for prefilling the query string part of the href. So they had an href with a mail to and then a query string of subject with the form subject body and the body text inside of the query string. So basically, like, you're using mail to pre-populate a query string, and that's the the thing. So obviously, I've added mail to email links with the websites dozens of times,

• 32:16Scott Tolinski?

  but I've never prefilled the content of that email based on the contents of a form. Imagine a customer selects boxes, chooses options, but when you come to send the inquiry, it gets sent to your personal email as plain text, which each of your chosen options added to your email. I think that would be kind of neat. I don't think I've ever seen this functionality in the wild, so I feel like there are some, must be some reasons not to do it. Here are the pros and cons. They list several different pros and cons. I'm going to say, without reading these out, mail to is not good enough because if I click on something and it opens up my Apple Mail, and I close it immediately,

• 33:01Scott Tolinski?

  and I never go to reach out to that person. A contact form in 2025 is essential for

• 33:10Scott Tolinski?

  Normies on the web, even me, I'm a tech ass person and I would lose it if I had to do something in a mail to link like this. So I think it's a fun idea. I think at the end of the day, mail to just not a 2025 experience, if you're asking me.

• 33:28Wes Bos?

  Yeah, regular people don't have their mail to configured properly. You know, it just opens up Apple Mail or whatever the one is. And if they're not using that as their app, then how do they know how to do that? And the other thing is that companies often need to be able to rigidly enforce what people are sending them. So if you just give somebody like a list, like, send me these 10 things, they're not going to send half of them. And then you got to email them back and it's way too much support. The reason people have contact forums is so that they can very clearly specify what you should send them. And also, they have many steps in front of that to try to solve their problem before

• 34:08Wes Bos?

  the email actually reaches your inbox. So, and also, I've done that, like the query string, subject and body in the past, and it works fairly well. But I do know that there's lots of, lots of email clients that don't support it quite. So if whatever weird email client you're working in, it might not necessarily work. All right. Subgrid Mitchell says, do you feel there is an increasing pressure for developers to become full stack? As a senior front end engineer, I'm seeing a troubling trend of full stack roles being advertised as front end. It's been so demoralizing for me. I love the front end creative side of things, but now I feel like I'm being asked to do more work for about the same

• 34:52Wes Bos?

  pay. What is even a path to full stack if I did? Or should I just leave the industry? Because what I really like is being creative. And now these employees seem like they devalue that. Would love to hear your thoughts on this.

• 35:06Scott Tolinski?

  Yes, I think the job of a web developer is just to get it done. It's always been so weird to me that people think that they can just say, I am just.

• 35:19Wes Bos?

  Going to be doing CSS. Like that was the thing is like there used to be people who only do CSS and don't touch JavaScript.

• 35:25Scott Tolinski?

  Yeah.

• 35:26Wes Bos?

  I'm only going to be touching the front end and all that backend stuff. That's somebody else's job, not my, not my paycheck. You know, I'm not getting paid enough to, to do, do that type of stuff. That makes absolutely no sense to me. You are trying to build experiences for the web and you need to use whatever the hell you need to, to do to, to make that kind of thing. And you might be a little bit stressed out because your skills don't extend back. But the, the relationship between server and client is getting significantly blurred. Being able to use AI to build is, is allowing people to do stuff they not necessarily have been done before.

• 36:08Wes Bos?

  Whether that's a good or, or a bad thing, you should be able to do the full stack. That's not to say you shouldn't be able to focus on something if somebody necessarily needs that. But I do think that the future of building for the web is being a full stack developer where you're able to write some CSS, build UI, and it's not just creative, it's you're solving problems both on the server and on, on the client. And if that is a UI challenge that you need to build, absolutely. Or if that's a performance issue and saving to the database and, and queuing things up, then, then that's what you need to do as well.

• 36:44Scott Tolinski?

  It's interesting to me as somebody who came into this industry as an agency developer and like, we weren't called full stack developers, but I was writing PHP sites. I was writing CSS. I was doing the database. I was a full stack developer. You know? It was always weird to me that there were people who would just do just the CSS or just, you know, because it just, just did not like, I, I was like, man, that would be crazy to focus on one thing.

• 37:15Wes Bos?

  Here's a question, a follow-up I have for you is, do you think we are going to see a wave of people? Like almost rage quitting because of things like this and because of the whole new generation of having to learn AI and having to integrate that, do you think that there's going to be a lot of people being like, I cannot do this again. You know, I just learned React over the last five years. I cannot deal with this whole new wave of of web development.

• 37:44Scott Tolinski?

  I mean, maybe, but like, it's not something I could personally understand. As a person who works on the web, like, it's always been of my mind that my job is to understand how the web works, how the browser works, how everything fits together. You're never building a website, you're you're building all of the, you're building all the stuff. Even if I'm not touching the CSS, which is never the case for me, I still need to understand the structure that makes the most amount of sense. I still need to understand how JavaScript APIs integrate with CSS or HTML APIs. I need to understand big picture. And so like, I would have a hard time at this point being like,

• 38:28Scott Tolinski?

  that not being my responsibility, that's always been my responsibility. Even if I'm not writing the CSS, it's always been my responsibility to understand how this this all works together. That's just how I've always seen it. Yeah.

• 38:41Wes Bos?

  I, I, you see the same thing in other like creative industries as well with like, like video editors, you know, like Producer Randy is a, like a video producer, but like, he also knows a hell of a lot about audio, and he knows a hell of a lot about YouTube thumbnails, and he knows a lot of, like, he'll write some, he writes some code if he needs to, if that's what he needs to do to solve his problems, he'll go and write some code. And it's not like he's gonna sit there and be like, hm, I'm only an audio guy. I don't do video, or I'm, I, that's not above my pay grade, that type of thing. Those people, you see that all the time. I'm sure this happens in the trades as well, you know, not my job, not gonna worry about that,

• 39:26Wes Bos?

  I'm focused on this one thing.

• 39:27Scott Tolinski?

  Yeah, exactly. Yeah, I, it's a weird mentality for me to get behind the it's not my job thing. Your job is to, to build great experiences on the web and you should know how it all works together. And if that means you're doing it with AI, if that means you're doing it with this or that, if you're, you're using new CSS APIs. It's like the people who are like, I'm sticking to my floats or whatever. I don't need to learn all this new fancy CSS stuff. I mean, it's like, there's gonna be people who say that about absolutely everything. Their mentality was, I learned it once, I don't need to learn it again. This was never the right career path for you, if that's the case.

• 40:03Wes Bos?

  Can I tell you a story that I often will, I often bring up to people when, when I encounter this is my, when I got the very first iPod in high school, I freaking loaded that thing up with, with like however many songs you could put on, a couple hundred.

• 40:19Scott Tolinski?

  Which, which was your first iPod?

• 40:20Wes Bos?

  My first iPod was, I think, this one. Let me look.

• 40:25Scott Tolinski?

  The first one had clicky buttons. Mine had a glass front, which was all capacitive buttons. And then the next big one had like a gray circle where you actually pushed on it. So my first one was the all glass front with the red glow underneath the buttons.

• 40:43Wes Bos?

  That was mine as well. Yeah. Where it had the, the capacitive buttons up top.

• 40:47Scott Tolinski?

  Yes.

• 40:48Wes Bos?

  So I brought that thing on the bus the next day and I was, I was so stoked because everyone had Discmans and I was.

• 40:55Scott Tolinski?

  No one had an iPod at that era. Yeah.

• 40:57Wes Bos?

  No, I was the very first person to have, have an iPod and I showed all of my friends. I'm like, holy crap, look at this. I've got every, I got a whole book of CDs on here, like a whole binder.

• 41:09Scott Tolinski?

  Breakout on it.

• 41:09Wes Bos?

  And my one friend on the bus goes, I just don't see why you'd want that. And like, that's it? We're, we're done? The CD is the best we're gonna do? Like a, like a spinning piece of shiny plastic? With 12 songs on it? That's the end? We're there? Like, you don't, you cannot fathom anything past that? And, and you think that this iPod is stupid? And that bugged me so much because it's just like, there's some people out there where they're just like, that's it. That's, I'm happy with that. And I'm kinda jealous of those people as well. I'm, I'm jealous of people who can drink Folgers coffee and, and think it's good.

• 41:44Scott Tolinski?

  Oh dude.

• 41:45Wes Bos?

  It's just simple.

• 41:46Scott Tolinski?

  I lament this all the time. Yes. I wish I could leave the simple life many times, but no.

• 41:51Wes Bos?

  But man.

• 41:53Scott Tolinski?

  Yeah, we, we had, yeah, I don't know which it's either, I think it might be the third, third generation was the one that we both first had. The first time I ever saw one was the second generation, which is a big chunky guy and it had clicky buttons and a kid in my school had it and I was just like, what is this? And it probably had like 15 or 20 gigs. My first one had 40 gigs, I think. I don't remember, somewhere around there. And I didn't get another one until they had color screen. So I had that thing forever in college and stuff. It didn't have a backlight even. So it was, yeah, ancient. But man, that was game changing for me.

• 42:29Wes Bos?

  I think the third generation is what it was. And then that was before we had the color version. By the way, remember people used to call the iPod Touch the iTouch?

• 42:40Scott Tolinski?

  I hated, yeah, what?

• 42:41Wes Bos?

  People that do-

• 42:42Scott Tolinski?

  Cause that was not the name of the darn thing.

• 42:45Wes Bos?

  It's not the name. No, that's, that's not it. And pretty sure Randy just had a TikTok about like things that drive him nuts about people that have the spoon upside down and like, mm, you know, they're like, that bugs me. But like, the one thing that kills me, and I still get mad about it, is when people called it an iTouch.

• 43:02Scott Tolinski?

  Oh, yeah.

• 43:02Wes Bos?

  And it's like, it's not, it's not an iTouch. It was iPod Touch.

• 43:06Scott Tolinski?

  Yeah. Yeah, that's weird. Yeah.

• 43:09Wes Bos?

  Thank you for coming to my TED Talk. Next question, what do we got?

• 43:14Scott Tolinski?

  Um, next question, yes, from Joe Young. I added Mighty here because there's a movie, Mighty Joe Young, about a gorilla, and I thought that was funny. So Mighty Joe Young, long time listener, first time caller. Do you have any recommendations on what pre-commit checks to run and how? Aside from the general pre-commit practice of just looking over my code thoroughly and letting the editor flag any errors, I'm not sure of the most efficient way to automate the process a bit more. I tried things like Husky or writing manual hooks for things like linting and I just- Getting into a tangled web of ESLint errors. That's if I even pass what feels like a large difficult hurdle of getting these things set up correctly. It feels like such an annoying task.

• 43:56Scott Tolinski?

  I don't think pre-commit checks should be limited to linting. I'm just not sure if there are other best practices or things to check for, but I want to be better at my area of development. Also, the stickers from the newsletter totally rule. Thank you, Joe. Yeah, pre-commit hooks, for me personally, have always seemed like too much effort. Because like you mentioned, it always kind of is a pain to set up. And what I ultimately end up doing personally is having a process where I'm running checks as a part of my development process, and then I'm running checks in my PR and code review process. So the only time I get into pre-commit stuff is if I'm working in packages that need to get published and things like that.

• 44:39Scott Tolinski?

  It's creating a new version of the package, et cetera, et cetera. But yeah, that's it for me. I don't know if it's ultimately worth it. It depends on what you and your team decide. Wes, you look like you might have some thoughts here, but...

• 44:51Wes Bos?

  I haven't used a pre-commit hook in a long time. I used to have them set up for linting, for formatting, type checking, all of those types of things. And a lot of those things have now moved to GitHub Actions, where they just happen asynchronously. And you just throw like a commit in there, you know? Like let the GitHub action format the code if it's not correct, or throw up a linting error. If the person didn't run the linter before they put their commit in, and then now they have a pull request in, then you can just fail the pull request against that. So I agree. They've always just been more of a pain in the butt, especially when you're trying to get like third-party contributors.

• 45:36Wes Bos?

  So I'm not a huge fan of them. Maybe for things like bumping the version. That's one thing that like, yeah, like version bump, release, cut a new release.

• 45:47Scott Tolinski?

  I still do that as a GitHub action.

• 45:48Wes Bos?

  Yeah.

• 45:49Scott Tolinski?

  I almost always read it just because it's the tool I know, you know?

• 45:52Wes Bos?

  Yeah, yeah, that's true. Yeah, most of my stuff has moved over to GitHub Action and then things that must happen, I just kind of remember to do them before I send in the pull requests or run it after when I realize my PR has been failed.

• 46:08Scott Tolinski?

  Yeah, if you're out there and you're using pre-commit hooks for something that are essential and that like is the best way to do that, let us know because I'm curious.

• 46:17Wes Bos?

  Matt says, "Hi guys, I've recently come into a codebase for an app which was poorly built by a single outsourced developer. The backend is PHP and one example of its problems is the changes are literally copy pasted from the dev's machine to the running server to update it, meaning we're making updates at 3 a.m. to prevent interrupt it." Oh my gosh. "This, along with other issues, means that changes are difficult. Downtime is common and the whole thing feels ready to be collapsed. I want to migrate to something like Firebase so we don't have to worry about all of these things, but the app has grown to a few thousand active users very quickly. Do you have any advice for migrating at that scale without

• 46:59Wes Bos?

  impacting users too much, or would you just grit your teeth and make the existing server work?" Man, I think there's so much you can do in between copy pasting your changes at 3 a.m. and like migrating the entire thing to a different language and putting it on Firebase. People write good code in PHP surprisingly. There's lots of PHP code out there and I would very first just implement some sort of version control and some sort of release strategy. That is very basic. It's gonna get you there and that might mean you have to buckle down and write a whole bunch of PHP, but I would think so. Or if

• 47:44Wes Bos?

  you really wanted to, if you really wanted to re-implement it...

• 47:50Wes Bos?

  You just have to write like a script that will migrate the entire database. And then you can build the entire app. And then you'll have to rerun that script again before you actually cut over to this new thing. And make sure that all of the features are still working.

• 48:08Scott Tolinski?

  I'm the type of person who always looks at these things optimistically first and foremost. And like I've had to get better with that with age. So like when I see this, the first thing I think of is a certain part of me would think just how nonchalantly it would be easy to migrate something like this. I don't suggest you don't migrate it because migrations have worked out well for me in the past. They've also become a giant headache. But I do think what you need to do is take a very, very, very deep, realistic view at what all exists and what could be the massive pitfalls. Cause I think oftentimes we gloss over the things that are going to be big challenges

• 48:52Scott Tolinski?

  and just assume that they are just challenges. So just take a firm look at what really would be the lift for this before you make a decision. Because you know, at the end of the day, a migration could be a great decision. Not saying that it couldn't be, but like, just know, yeah, just know.

• 49:11Wes Bos?

  The thing about moving from one language to another is a lot of the logic will still stay the same.

• 49:17Scott Tolinski?

  Yeah.

• 49:18Wes Bos?

  And like, we talked to the folks from TypeScript when they ported it to go. They're literally just went function by function and transferred it over to go. So it really depends on how big this, this actual codebase is and how much you can do there. But yeah, it's not, not crazy, you know? Like maybe you can just say like, hey, Boss, give me three days and let me see how far I can get in three days. And like if then you can kind of like look up and be like, all right, this seems doable, you know, there's here's a couple of hard parts and here's how we're going to approach this. But or you might come out of that being like, you know what? This thing is a monster and there's it's not worth moving it over to something entirely different.

• 50:04Scott Tolinski?

  Word.

• 50:05Wes Bos?

  Last question from CJM. Hi, Wes and Scott and maybe CJ. Nope, not today. What GitHub Copilot features do you recommend disabling while you're learning something new? Thanks for the awesome show. Oh, this is a good question. Do you have anything that you would you disable when learning something new?

• 50:22Scott Tolinski?

  If I'm learning, learning something new, I typically disable the autocomplete. Cause the autocomplete can make choices that are not correct sometimes and that can actively harm you. And I'm thinking like you're working with a new library or the library is like a newer version. It can be giving you older code sometimes. It can be giving you wrong version of code. It can be thrown a bunch of tailwind classes in there for no reason. Like, there's a lot of stuff that can come along with the autocomplete and it's so overly hyperactive sometimes that you're like, all right, and I've largely kind of moved away from using the autocomplete at all, really.

• 51:02Scott Tolinski?

  The times that it helps out the most is when you need to do a lot of like repetitive work. And it can like save you on repetitive work. But when I'm learning, I don't want that around at all because I'm not doing repetitive work. I'm doing deeper work.

• 51:18Wes Bos?

  I find that I disable the like tab completions and the inline suggestions a lot. Not necessarily when it's something new, but when it is something complex that I really need to think about. Because it will try to be like, hey, how about, like, just wait a sec. Let me think about this for just a second while I'm doing it. And I just have to turn it off because it requires, it's not like a, like a mindless. Yeah, I have to put a div and four buttons on the page and yeah, we can do that. But it's just like, let me really think about how I should be structuring this type of thing. And if it tries to like get in there, I'm just like, no, you, you sit on the sidelines for a bit while I, I give this one a good think.

• 52:04Scott Tolinski?

  Well, I think that's about it for our potluck questions today. If you have a question for us over at Syntax, send them over to syntax.fm and there's a form in the top navigation about asking some potluck questions. And we answer these at least once a month and we try to make sure that we get some good answers for you. So now it's the part of the show where we talk about sick picks and shameless plugs. A sick pick is anything that we have been enjoying lately. Is it anything that just rips for us? Stuff that we enjoy. I have a sick pick for you and I got, I actually do not remember if I've sick picked this. So you'll have to tell me if I have. I got something that I use way more than I thought I would ever use it.

• 52:49Scott Tolinski?

  I got an air duster.

• 52:53Wes Bos?

  Yes. I don't know if you have or not, but I've been, I'm very, very into air duster TikTok right now. So tell me about it.

• 53:00Scott Tolinski?

  Okay. So I watched, I was not planning on spending this much on an air duster because this one is expensive, which is ridiculous, but I watched, what's the guy who does all the tests?

• 53:12Wes Bos?

  Project Farm.

• 53:12Scott Tolinski?

  Project Farm. I watched the Project Farm.

• 53:14Wes Bos?

  They're not all built the same.

• 53:16Scott Tolinski?

  They're not all built the same and the Project Farm video convinced me that getting a nicer air duster was the way to go. This thing, I use it everywhere. I use it in my car. I, I can use this, I kid you not, as a leaf blower for my patio. I have a leaf blower, but like we have a patio set that gets leaves on it because we've got a big old tree. If we're going to go out, watch a movie, I'm not going to go get the leaf blower. I just got the little air duster, blow off the leaves. I use it on my desk, computer, everywhere. This thing absolutely rips. It is the fastest darn little air duster on the planet and I, I just adore it.

• 53:58Scott Tolinski?

  I, I thought, I was like, yeah, I'll use it. I could use an air duster for, you know, cleaning off my desk, which is why I got it, or my computer, or just the general air duster tasks. Cause I didn't want the little, you know, spray things in the house. They're just like, you know, disposable, whatever. Rather get something permanent and boy howdy, this thing rules.

• 54:20Wes Bos?

  I really want to get one of those, especially for like around the barbecue and, and you can, you do it right now. Do your hair. I want to see it.

• 54:31Wes Bos?

  Nuts.

• 54:33Scott Tolinski?

  Here, I'm holding it way out here.

• 54:39Wes Bos?

  You know why we're starting to see these air dusters absolutely everywhere? A little bit of manufacturing history for you. China has reverse engineered the Dyson motor.

• 54:50Scott Tolinski?

  That's

• 54:51Wes Bos?

  And you can go on AliExpress and for like 15, 10, 15 bucks, you can buy like a wicked, wicked little motor that spins incredibly fast for like dirt cheap. And it's really interesting now that like, cause when Dyson put out the, that like, you know that hair dryer that everyone has now they have the air wrap and they have all these like really neat hair, hair product accessories? They made, and now they actually have like a really cool stick vacuum. That's

• 55:21Scott Tolinski?

  I was gonna say, have you seen the stick vacuum? Yeah.

• 55:23Wes Bos?

  Yeah. And they're all using this like, this motor that Dyson developed and it's, it's actually a very interesting motor, which is people give Dyson a lot of flack these days because their batteries die forever and they feel like they haven't innovated, but they, I'm pretty sure they made that motor, but now it's been, it's been duped over and over again. And you can pick one up for 15 bucks on AliExpress. And now you're seeing all these crazy products that have these insane motors in them.

• 55:51Scott Tolinski?

  Yeah, yeah, it's, it's wild. And some of these actually do function as little vacuums too, but I never found one with great reviews. So it just like, wasn't a feature that I needed.

• 56:01Wes Bos?

  Oh yeah. You're more of a blower, not a, I don't know, maybe we should cut that out. Not even gonna continue.

• 56:09Scott Tolinski?

  We, we don't have to cut that out, but you don't have to continue that. Yes.

• 56:13Wes Bos?

  Okay.

• 56:13Scott Tolinski?

  That's hilarious.

• 56:14Wes Bos?

  I'll stop right there. Awesome. That's, I, I really want to get one of those. The only thing I'm concerned about is like, if you buy a cheap one, that's not well reviewed. They have like, they use a lot of battery very quickly. And if you discharge a battery too quickly, they can kind of get explodey.

• 56:31Scott Tolinski?

  Oh, okay.

• 56:32Wes Bos?

  Yeah. But you, you're not like me buying sketchy ones, so that's good.

• 56:38Scott Tolinski?

  Yeah, there are some things I'll sketch out on, but the air duster, for some reason, I felt like I needed to go premium with it.

• 56:44Wes Bos?

  Batteries is not something you should ever sketch out on, no.

• 56:46Scott Tolinski?

  Yeah.

• 56:47Wes Bos?

  I'm gonna sick pick kettlebell. I just got a new kettlebell, which I previously just had like the cast iron ones, you know? Like, weight is weight. It's like the most primitive thing ever, throwing it around. And I realized there's these things called competition kettlebells, which A, they look much nicer, and B, they're all exactly the same size, no matter how heavy they are. So I got a couple of these competition kettlebells, and they are really, really nice. Both just in your hand, they're obviously all the same size, so as you go up and down, the different weights, you're not like adjusting for different size of kettlebells. So I'm a big fan of it. I'll link up the one I got, but generally you just search competition kettlebell,

• 57:31Wes Bos?

  and you find one with like a stainless handle, and they are very nice to use, so I've been pretty happy with mine.

• 57:38Scott Tolinski?

  Nice. I love that. Yeah, I have a kettlebell that I use mostly for stretching. It's big ol' heavy. I put it on my whole, I do like this, and then I'll sit in the splits and do like a good morning on it.

• 57:48Wes Bos?

  Oh.

• 57:49Scott Tolinski?

  Yes. Big fan of that.

• 57:50Wes Bos?

  That's a good one. I should try that. How heavy is the one that you got, that you used for that?

• 57:55Scott Tolinski?

  Maybe like 35 or something? It's heavy enough to pull me down.

• 57:58Wes Bos?

  That's a big boy. I, mine is, oh yeah, mine's 35. 16 kilograms. Is it, is it yellow?

• 58:05Scott Tolinski?

  No, no, it's black. It's one of the big ol' just classic kettlebells. My buddy who you met on the show, Eric Sartorius, when he lived in Denver, he like moves places and he'll buy some like gym equipment and be like, when he needs to move, he can't like transport it because he's moving out of the country or something. So he was like moving to Germany or something, and he was like, "Hey, I can't take this kettlebell." And he's like, "I'll sell it to you for cheap." I'm like, "All right, I'll take a kettlebell."

• 58:29Wes Bos?

  That's sick. Cool. Alright, thanks everybody so much for tuning in, and we will catch you later. Peace.