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

Welcome to Syntax. We 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 got some really good questions on, should every developer be a full stack developer? A lot of people are 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 Versus Node tricks. Some really good questions today. Let's get on into it. First question we have here from Big Dave. When is the appropriate time to use request animation frame, and does it differ in React's Svelte Angular? Yeah. This is a cool question. Request animation frame is a function in JavaScript that essentially allows you to queue up some work that needs to be done. Mhmm. And very likely, that has has to do with updating the DOM or 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. Node, normally, you would think, okay. Well, I wanna run this thing like, maybe some some monitors are 30 frames a second, some monitors are 60 frames a second, and some monitors are a 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 as often as you want because it's it's computationally expensive, and maybe you're only gonna 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 request animation frame, meaning that 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 a certain amount and and so on.

So it's it's pretty nice because you don't really have to figure out how frequently you wanna run something. You just ask the browser, and it's going to figure it out for you. And people that have a 120 hertz displays that are running on super powerful machines are gonna get as fast as possible, and other people who who may not necessarily have that refresh rate or CPU power are are going to get a little bit left. So the question of when is the appropriate time to use request animation frame, essentially, anytime 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, Svelte, 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, interesting. But then everybody came out and be like, no. That's that's kind of a a moot optimization.

You know? Like, I don't think you should should we really been doing that. One thing I'll I'll 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 JS 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, thousand milliseconds, every 16 it's not might not be called every sixteen milliseconds if you're trying to to shoot for 60 frames a second.

So what can happen there is is sometimes you're on a website and the animations run way faster 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 as a choppy amount than than 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 or how far along the screen it is.

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

it's good. It's good.

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

Yeah. 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 a break or exit condition.

Yeah.

Alright. Next one from Mike w.

Just found your show four or 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. Thank you, Mike w. He's from BC. Good.

I'm from Bos, and Scott Svelte 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 Wes and how to do good and meaningful code reviews.

GitHub Wes can be super slow. I tried GitKraken and Versus 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 this specifically.

There are other apps like Git clients. Like, Git GitTower 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 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, will 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. 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 onto the person doing the code review to find those things.

Those things should be found with a tool, whether that JS, like, linting or 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 wanna look for and have a good eye for.

But in larger teams Wes people where you're probably spending a decent amount of time doing code reviews because, right, people are shipping stuff, people are writing code, multiple people, people have different coding styles.

I think your process ESLint general is something you'll wanna sit down and, like, really try to formalize.

Now granted, I 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 used GitHub,

for this. Wes, I think you just use GitHub, and CJ does as well. So I'll I'll tell you what I use in just a sec once you're done because I've got some thoughts here.

Okay. Well, you give me your thoughts right now. Let's let's have a fun chat. Let Eric, let me share my screen here. I use GitHub pull requests. It's a Versus Code Yeah. Versus Code extension. Extension.

So you use that for code reviews. Okay. 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, m p three 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 could write a script, but just to give it a a quick look over. Nobody so far has has helped me out. So,

dear listener, I have the same problems as you. My poor teammates are are not reviewing my I was on vacation, by the way. Actually, I was on vacation. I was on a work trip.

So I yes. I was on vacation. It. But, basically, my process is is like this. Right? So I'll I'll open up, the the pull request, 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 where also where I'm 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 it's a totally separate extension from the, like, source control, the the ESLint integration in Versus Code. It's an actual extension from GitHub called GitHub pull Wes, and I think it's highly under underutilized. I've been trying to force myself into the, like out of the terminal ESLint 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 the process of Checking. Reviewing pull requests. Yeah. Yeah. Yeah. My 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. Minus 900 files.

Right. But but it's it's it's marked down. 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 I can definitely get bogged down in a little bit of, like, my eyes glossing Vercel, and it looks good to me, type of thing? So I 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.

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, well, while I'm here, I might as well do this. Or in order to 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 and update the 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 wanna do is is stack them, meaning that you maybe update your dependencies first, open up a pull request for that, but then continue your work on, branch off of that work already.

Yep. 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.

Yeah. Yeah. I I 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 pull Wes that because, like, if you put so if your if your employee comes to you and JS like, here's this pull request with that. Right? The quick fix, this and this and that all in Node, and you say, I'm not going to merge this. Please bring these as separate pull 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 Yeah. A pain now to split that stuff out. So

yeah. I 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 kinda scanning it and running the tests and whatnot, AI is much better at those monotonous things and and possibly catching things that you should then review.

Yeah. Totally. Word.

Mike asks, could you give me some realistic examples of when to use the CSS ATTR function and when that might be useful? Why would a CSS value end up in HTML an HTML's data attribute? Is there a real world use case for that? So he's talking about in CSS Node, we're able to use ATTR to be able to access your HTML attributes.

And that's really exciting. We've been able to do it in, like, before and after pseudo elements, which was handy for, like, tooltips and whatnot. But now you're able to actually access all of the HTML elements attributes In Chrome. Chrome. Is is it all of them? Yeah. It's just in Chrome. Is it just data attributes?

Or I Wes I think it's just data attributes. I think it's just data attributes. Let's see. Let's double check that.

Node. No. It is it works Oh, yeah. Non string values. Ref, href as well. And that's that's really handy because you often wanna grab the h ref, the title, the alt, the maybe oh, wait. I don't it doesn't work with value because well, you can get value, but it's not updated. Like, if you if you have, like, an pnpm,

type of range You couldn't do, like, dynamic.

Yeah. And if the if the value will be whatever set JS default, but as you you Scott 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, 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.

Yeah. You could count, like, how many items should this be, how many columns. Like, imagine a declarative CSS grid. It's 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 dash 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, which is 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.

Yeah. Some people I have an pnpm see, I have an example where people are doing, like, like, citing sources and that kind of stuff. I I do think there once this works well with the upcoming if statements, once it works well with, style queries Wes 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'd pass a prop into a style component and then do an if statement in JavaScript inside of our CSS.

Mhmm. 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 Sanity 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. Mhmm. 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 you have all these different additional classes that could and make more sense to be, like props, which attributes can be seen as kind of, like, props and style it based on that rather than adding and removing another class here and there. And and I I think this makes it all a lot cleaner in my mind. And,

oh, 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 or any of these framework worlds because you can pass, like, an object, which is style. But, like, I even imagine this is gonna be killer for Tailwind because for Tailwind to be able to specify both, like, a property and a a value in a go is is gonna be great. Imagine you could do, like like, group equals card on an on an actual element, and then you can access that in in other spots of your CSS. And then, also with not passing the inline CSS JS 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 Vercel 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.

Word.

Alright. Next question from Luke.

Ruo Kaismaki.

Roas Kaismaki.

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 nine one one, 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.

I don't know that Brave solution with BAT. What is that? A basic access token?

No. Basic, attention token. Attention token. Yeah. JS that, like, you can, like, put money into your Brave, and then based on, like, the content you are consuming, some of that so 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

Yeah. In the early days. I have a decent amount of basic attention token because of YouTube.

In the past, I had connected Vercel 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 it's like if we're talking about, like, actual ad dollars or anything like that, it is, not very much.

So okay. I don't know that Brave Vercel 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, etcetera.

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 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 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 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 a big portion of it. Like, how many people are going to replace their general browsing of actual sites? And and and 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 Wes, and all those filtered into what? Social media. And social media, you got the few sites that you visit all the time. You got Instagram. You got Twitter. You got Facebook. Whatever. 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 normalize people using chatbots to get information all the time. I think we're gonna 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.

Dia, their search bar is essentially a chat window.

It's a chat window that you can ask about other tab. 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 a 100 times a day, why is Dia a a web browser for the computer 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 gonna 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 I I mean, who really knows about any of this stuff? But I do think that is going to be a shift, and and that's going to be a massive bummer for those of us who like the creative Wes. And I think the creative web will still be there. But, like, general CSS people, they're gonna be utilizing their browser as essentially the window to pulling in information

rather than having to go and visit sites. I've been thinking about this question a lot. Like, we saw it with newspapers. Right? Like, 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, it we Wes don't see it as much anymore. Now I I think about that with the web as well because, like 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. It's consumed by people, but a lot of it has been used to to train these AIs and and for people to just get a very quick answer. You can see the the amount of, like, bots visiting websites is going up significantly because you ask a question about JavaScript.

And it's like, woah. Let me just go suck in 40 pages of that. Talk about using JavaScript const variables and then just distill it down. And from a user point of view, I freaking love it. I don't want to spend half an hour reading through your your life story about x, y, and z. I just know how 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 have your actual answer. Right? So for those people who who do it for money, where those businesses are gonna be significantly disrupted.

Yes. And then, like, what happens to to people who rely on that money in order to put information out on the Internet? I I don't I don't know. But it's it's a tricky thing because I 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 I don't know. I hope it means end of the, like, awful clickbait.

Here are 14 things you must see in in Italy when you visit. You know, like, all those, like, awful websites that have popped up over the last five, ten years where it's just, like, garbage SEO content? I hope it means it's it's the end of that. But, unfortunately, I also think it's gonna be the end of people putting out very helpful information. You know who I wanna get their thought on this? Who? And who I think that got got I don't know if they got out in the right time. Chris Coyer. 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 he the CSS tricks was such a huge swath of information Changed my life. 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, JS the next CSS Trix is is not gonna make that much money. He's not gonna not gonna be able to dedicate those those resources to it. So I'm very curious to see what his thoughts are on creating and writing content and information and putting it out there when Yeah. The the upside to it is is is much smaller. It's just these AIs are gonna gobble it up and and short form it for your our our brain rotting, people right now.

Yep. Yeah. I know it's all it's all, we're now Yeah. We're Node. 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 and see how these things work. There will be some bad things, and there will probably be some good stuff that comes out of it as well. And there'll probably be some things we don't see coming.

There's that's For sure.

Things things work. Yeah. Yeah.

And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.i0/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 century.i0/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

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 Versus Node. I have searched the Internet for four hours, and I was sure you had mentioned 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 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 in the browser for you. Because I'm sure you could 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 the Vite directory contents.

I think you can just run n p x viter, and it will fire up just a regular Vite process, but it will also make a direct 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 wanna 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.

Yeah. It's tough too in a component based flow. You know? Like, how many times you at the root page and how many times JS that you Node? 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 look mostly just working your specific use case that you need to very simple.

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.

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

Yeah. Totally word. Alright. 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 are. Normally, I would use an external service, possibly forms free, resend, Netlify forms, whatever. But I just had the thought that it could be done use a simple mail to anchor href for pre filling the query string part of the h h ref. 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 prepopulate a query string, and that's the the thing. So, obviously, I've added mail to email links with the websites dozens of times, 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 a while, 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 gonna say, be without reading these out, mail to is not good enough because if I click on something and it opens up my Apple Mail and That's okay.

I close it immediately, and I never go to reach out to that person. A contact form in 2025 is essential for 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 a 2025 experience if you're asking me. 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 gonna send half of them, and then you gotta email them back, and it's way too much support. The reason people have contact forms 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 the 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 Wes, but I do know that there's lots of lots of email clients that don't support it, quite. So if if whatever weird email client you're working in, this might not necessarily work.

Alright.

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

Yes. I think the job of a web developer is just to get it done. I it's always been so weird to me that people think that they can just say, I am just 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 or Yep. I'm only going to be touching the front end and all that back end 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 kinda 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, 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 Wes 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 and saving to the database and and queuing things up, then then that's what you need to do as well. 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 Wes always weird to me that there were people who would just do just the CSS or just you Node? Because it just

Wes did Scott, like I I was like, man, that would be crazy to focus on one thing. Here's a question a follow-up I have for you JS, 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 gonna be a lot of people who've been 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.

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 Yeah. How everything fits together. You're never building a website. You're you're you're building all of the you're building all the stuff. It even if I'm not touching the CSS, which is never the case for me, I still need to understand the structure that makes this 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, that not being my response, but 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.

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 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'll write some code if if he needs to if that's what he needs to do to solve his problems, he'll go and and write some code. And it's not like he's gonna sit there and be like, 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. I'm focused on this one thing.

Yeah. Exactly.

Yeah. I 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.

Can can I tell you a story that I often will I often bring up to people when when I I encounter this JS my when I got the very first iPad in high school, I freaking loaded that thing up with with, like, however many songs you could put on a couple 100. Which which was your first iPad? My first iPad was, I think,

this one. Let me look. 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.

That was mine as Wes, yeah, where it had the the capacitive buttons up top. Yes.

So I brought that thing on the bus the next day, and I I was so stoked because everyone had Discman's, and I was Deno one had an iPod at that era. Yeah. No. I was the very first person to have have, an iPod, and I showed all 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 point here. Breakout on it. 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 You got 12 songs, and that's it. 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 iPad 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. You know? Dude. It's just simple I lament this all the time. Yes. I wish I could leave the simple life many times. Yeah. But no. But, man. Yeah.

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 JS 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 till 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. 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? I hate it. Yeah. What People that do because that was not the name of the darn thing. That'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 Sanity, about people that have the spoon upside down and, like, a, you know, they're like, from and I was 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.

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

Yeah. Yeah. That's weird. Yeah. Thank you for coming to my TED Talk. Next question. What do we got?

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 get 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. 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. Recommit hooks. For me, personally, I've 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 JS 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. It's creating a new version of the package, etcetera, etcetera.

But, yeah, that's it for me. I don't know if it's it's ultimately worth it. It depends on what you and your team decide. Wes, I you look like you might have some thoughts here. But 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 Wes they just happen asynchronously.

And you you just throw, like, a commit in there. You know? Like, let the GitHub action format the code if it's if it's not correct or or or throw up a a linting error. If the person didn't run the linter before they they put their commit in and and then now they have a pull request in, then you can just you could just fail the fail the pull request against that.

So I 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.

So I'm I'm not a not a huge fan of them. Maybe for things like like bumping the Vercel.

Yeah. That's one thing that, like yeah. Like, version bump, release, cut it, Node release. GitHub action. Yeah.

Yeah. I almost always read it just because it's the tool I know. You know? Yeah. Yeah. That's true. Yeah. Most most of my stuff has has moved over to to GitHub action. And then things that must happen, I just kinda remember to do them before I I send in the pull request or run it after when I realized my my PR has has been failed.

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.

Matt says, hi, guys. I've recently come into a code Bos for an app which Wes poorly built by a single outsource developer. The back end is Pnpm, 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 3AM to prevent interrupt 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 impacting users too much, or would you just grit your teeth and make the existing server work? Man, I think there's there's so much you can do in between copy pasting your changes at 3AM and, like, migrating the entire thing to a different language and and putting it on Firebase.

People write good code in PHP. Surprisingly, there JS good 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 Bos. It's gonna JS gonna get you there. And that might mean you have to buckle down and write a whole bunch of PHP, but I I would think so. Or if you really wanted to if you really wanted to reimplement it, you just have to write, like, a 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 are still working.

The 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 at 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.

Because I think oftentimes, we gloss over the things that are going to be big challenges and just assume that they are just challenges. So just take a 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. The thing about moving from one language to another is a lot of the logic will still stay the same. Yeah. And, like, we talked to the the folks from from TypeScript when they ported it to Go. They literally just went function by function and and transferred it over to to Go.

So it really depends on how big this this actual code Bos is and and how much you can do there, but, yeah, it's not not crazy. You know? Like, maybe you can just say, like, hey, Bos.

Give me three days, and let me see how far I can get in in three days. And, like, if if then you can kinda, like, look up and be like, alright.

This seems doable. You know? There's here's a couple hard parts, and and here's how we're gonna 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.

Word.

Last question from CJ m. Hi, Wes and Scott and Mavy. 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 would disable when learning something new? If I'm learning learning something new, I typically disable the autocomplete

because 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 Yeah. 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, alright. And I've largely kind of moved away from using the autocomplete at all, really.

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.

I find that I disable the, like, tab completions and the the ESLint suggestions a Scott, not necessarily when it's something new, but when it is something complex that I really need to think about.

Yeah. Because it will try to be hit. Hey. How about how like, just wait a sec. Let me think about this for just a second while while I'm 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 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.

Well, I think that's about it for our a potluck question today. If you have a question for us over at Sanity, pnpm me over to Syntax dot f m. And there's a form in the top navigation about asking some potluck Wes. 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'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 just rips for us? Stuff that we we enjoy.

I have a sick pick for you, and I got 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. I got an air duster.

Yes. I don't know if you have or not, but I've been I'm very, very into air duster TikTok right Node, so tell me about it. 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? Yarn. Project Farm. I watched the Project Farm. All built the same. 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 got a big old tree. If we're gonna go out watch a movie, I'm not gonna go get the leaf blower. I just got the little air duster blow off the leaves. I use some of 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. I I I thought I was like, yeah. I'll use it. I I could use an air duster for, you know, cleaning off my desk, which is why I got it, or my computer, or or just the general air duster task because 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 Bos howdy, this thing rules.

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

Nuts.

Here. I'm holding it way out here.

Okay.

Oh my god.

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

That's a definite 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, like because when Dyson put out the that, like, you know Node hairdryer that that everyone has? Now they have the Airwrap, 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 the same thing. Have you seen the stick vacuum? Yeah. The stick vacuum is crazy. 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 Vercel, 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 on AliExpress. And now you're seeing all these crazy products that have these insane motors in them.

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

I don't know. It's maybe we can cut that out.

It's not even gonna continue. We we don't have to cut that out, but you don't have to continue that. Yes. Okay. Yeah. Hilarious. I'll stop right there. Awesome. Yep. That's I I really wanna get one of those. The only thing I'm con 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 kinda get explodey.

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

Yeah. There are some things I'll sketch out on, but,

the air duster, for some reason, I felt like I needed those premium ones that I could never sketch out on. No. Yeah. I just take a pick, kettlebell. I just got a new kettlebell, which I previously just had, like, the cast iron ones. You know? Like, weight JS weight. It's like the most primitive thing ever, throwing it around. And I I realized there's these things called competition kettlebells, which the, 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 Node. Both just in your hand. They're obviously all the same size. So as you go up and down, the different different weights, you're not, like, adjusting for different size of kettlebells. So I'm a big fan of it. I'm I'll I'll link up the one I Scott, but, generally, you just search competition kettlebell, and you find one with, like, a, stainless handle. And they're very nice to use, so I've been pretty happy with mine.

Nice. I love this. Yeah. I have a kettlebell that I use mostly for stretching. It's big, old 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. Oh. Yes. That's a good Big fan of that. Try that. How heavy is the the one that you got that you used for? Like 35 or something. It's heavy enough to pull me down.

That's a big boy.

I mine oh, yeah. Mine's thirty five. Sixteen kilograms. Is it is it yellow?

No. No. It's black. It's one of the big old just classic kettlebells. Oh, yeah. My, my buddy who you met on the show, Eric Sartorius, when he lived in Denver, he 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, alright. I'll do it. Let me get kettlebell.

That's sick. Cool.

Alright. Thanks, everybody, so much for tuning in, and we will catch you later.