Potluck Part 2 - Magic GQLess × Are classes dead? × Custom Hooks × Staying Up To Date × CSS × More!

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready. Here JS Scott Tolinski and Wes Bos.

Welcome to Syntax. This is the podcast with the tastiest web development treats out there. Today, we have another potluck for you, which is we should do 1 potluck per, per week. Or Node. What? 1 potluck per month. But we've we've got a lot going on in our lives right now. We're a little bit, a little bit slammed, so we thought let's just do another pollock. Plus, like, these pollocks are probably my favorite to do, and they get the most listens. So we thought we'd we'd treat you with an extra one. They yeah. They're also very, very helpful. I think they're very helpful. Oh, yeah. I think you get a you get a lot out of these potlucks because there's so many different topics that we can talk about.

Today's sponsors are Sentry, which does all of your error and exception tracking, and FreshBooks, which is does all of your invoices and expenses tracking.

We'll talk about them part way through the episode. With me, as always, is mister Scott Tolinski. How are you doing today, Scott?

I could be doing better.

No. You know, it's it's things are just crazy. I mean, they're crazy for everybody. But, if my audio sounds any sort of different than normal, it's because I apparently, Landon came into my office and then just just annihilated my setup.

It's so I've been spending all morning trying to get it back to where it was, because I had it you know, I had it tuned perfectly. And, he you know, I asked him I said, Landon, did you touch any of these knobs or buttons? And he says he says, I just counted them.

And I said, oh.

So that to me is, like, a big red flag. Because when he counts stuff, he's just pushing and whatever. Like, he's not just counting. So

I just counted them. Yeah. Oh. Did you have a picture of of your knobs to go back to, or did you have to do it by ear? No. Because I have tweaked it over time, and I had to do it by ear. And I have this I have a Cloudlifter

preamp in here. And for those of you who don't know the whole setup, basically, what we have is a rack mount with, Sanity, which has, like, I don't know, 10 knobs on it, which control, sort of Ask Landon. He knows how many the knobs are. He knows. He's been counting them. Although, he doesn't count he counts he counts he knows his numbers and he counts very well, but he just, like he'll, like, ignore he'll just, like he'll get to the number. He'll be like, alright. There's 5. And then he'll just keep counting even though he'll he'll like, he knows that's the end. He just likes to count continuously.

Either way, there's a compressor. There's a gate. There's a whole bunch of stuff. And, for my microphone to sound nice, it is very specific, very specific. And, yeah, no. Mm-mm.

So, hopefully, it doesn't sound too bad for you today. I'm gonna do my best to monitor it as we go. And if I notice anything, I'll tweak in here and there. But, yeah, that that's pretty much how Scott only today, but this whole, whole month has gone for me. So yeah. Oh, yeah. Yeah. My whole month is a a a set of mismanaged knobs here.

I I don't even have my, the DBX on right now, which is the the compressor and everything you're talking about, because I brought it up to the Scott. We actually have another one up here, and I realized it didn't have the cord for it. Mhmm. And some lucky soul I like, for those who don't know, my cottage is in, like, a super small town, Northern Ontario.

Some nice audio engineer drove 20 minutes to meet me halfway, and he just gave me the correct cable, which because, like, there's no way I could get anyone any other way because Amazon's not mailing stuff out, and I needed it quick. So, I just got it yesterday. I haven't hooked it up yet, though.

Yeah.

That's cool. Well, props to that guy for for Yeah. Yeah. Super nice guy. He said he had a garage full. He's engineer, so he's, like, I have every cable ever.

Nice. So he hooked me up. Alright. Let's get into the questions here. First Node is from Dan Chonery.

Chonery? I

I It looks pretty ton of air. Yeah. Chon of air. Yeah. Sounds good to me. Do you have a quick overview how to effectively use a platform like Cloudinary? I have a Gatsby site which has a lot of images, and want to use something like Cloudinary for optimization, but the docs aren't completely clear how to get the most out of their service. Okay. So Cloudinary is a service that you can upload images to or just feed images to, and then it will return, resized, compressed, different formats, sepia tone, all of that.

Cloudinary JS one. They've they're been a sponsor.

There's another one, Imgix, I m g I x. I haven't used that one before myself, but they they do Scott of the same thing. So the idea is that you just, like you pass it an image and it returns multiple sizes to you if you want.

I really like Cloudinary because, it allows you to do it on demand.

And you can just put it in the URL structure, and it will return that resized version Vercel something like Gatsby Image. You have to know ahead of time what size, you want the image to be.

So how do you use it with something like Gatsby? Well, there Yarn, different plugins for, Cloudinary. I'm assuming there is a Gatsby Image. So all most of I think all of the stuff that Cloudinary does, Gatsby Image. So all most of I think all of the stuff that Cloudinary does, Gatsby Image will do as well. The only downside to it is that, you have to process them all on your computer versus Cloudinary Vercel.

And for me, at least, that was that was giving me, like, 20, 22 minute build times with just I don't know. I think I had maybe 400 images with 3 or 4 different versions each. So, I've I'll talk about I've I'm redoing my website right now. I'll talk about how I solve that, in the future, but that's just kinda how you would use them together. Have you used Node Gatsby and Clinary together?

I haven't because, like you mentioned, the Gatsby image stuff is really good, especially just because you host your images locally. And and I I I should put a caveat to what you were saying if you have the images and your your computer or your servers having to crunch those.

It's only a problem if you have a lot of images. Right? Like, you have a lot of images. Is that correct? I wouldn't even say I have a lot. Like, I was surprised at

how I hit it. Like so I have a website. I have about 40 blog posts or may maybe, yeah, I I think I have 40 blog posts and 250 hot tips. Mhmm. And every blog post and hot tip had 1, maybe 2 images. Okay. So about 400 images. That's a lot that's a lot of images. No. It's not. It's not a big website. It's a lot of big. About, like, any website out there, I don't think that that's all that big. Like, you think about a ecommerce website. If you have, you know, 10 products You have 10 images. Each of 10 images for each product, a 100 images already. Right? So that's that's a 100 images, and then you you think about, like, a a couple different sizes each. You have, like, a thumbnail version, a medium version, a large version. And then if you're if you're doing responsive, it gets out of control real quick. And Gatsby and Netlify are both working to fix this right now because they realize how dog slow this can be.

You know, so okay. So I I you do use Cloudinary on my site. And so I think if you're looking to use Cloudinary and not use Gatsby images for whatever reason. I guess maybe, like, the way I use Cloudinary can either be of 2 ways. I have an image that already exists, and I'm using their upload URL to is it the uploader or the fetch URL? I guess I'm confused by those. Let me see. You mean, like, the URL that you put in front of your paths and it slurps it up? It slurps it up. Yeah. I I call that the upload or the slurp URL. The slurp URL. Because I had images that were coming in from YouTube's API, and I wanted get I wanted Cloudinary to slurp those up. So Cloudinary would just slurp those up.

Sometimes, though, what I do is I actually go to Cloudinary's interface. I upload the image via their click button Node and drop, and then I just it it like, I don't I'm not gonna do that for batching images. But if I have a one off here for, like, the syntax logo on the, Vercel up tutorials website, I just upload that by hand, and then I have the URL in here. And then as far as, like, the parameters in Cloudinary's parameters, I think as far as getting the most out of their service goes, one of the things that I've really loved is the f underscore auto parameter, which gives you the the format auto based on whatever browser. So, therefore, a, Google, their Chrome, they're gonna send you a WebP, to give you it's Wes. Right? Not WebM? WebM is movies? Yeah. WebM is for movies. Yep. So they're gonna send you a WebP, which is going to be a smaller file size than a ping ping PNG, whatever.

And, you don't have to do anything. And the browsers that are going to not accept a Wes, like crappy Safari, They're Scott they're not going to get it. So, they're gonna get the actual image. So I personally prefer to yeah. I use the q auto, which is quality auto, and I use f underscore auto for format auto. So that way, I get the quality auto and the format auto, and it just Scott of takes care of itself. You know what? One other thing I'm gonna use Cloudinary for on my website

is I am, pulling in my Instagram photos Yeah. Via the API into the footer, and there's 2 problems with that. Like, first, I I don't wanna use Gatsby Image because I don't wanna rebuild my website every time I post in Instagram. I so I pull it in client side. But the problem with that is the images are much larger than they need to be for the thumbnails they are in, and the Lighthouse complains about that. And second, is, like, Firefox blocks Instagram and Facebook. Oh, yeah. I think I have some sort of thing on. So, like, the the images don't work. And, also, I don't want to I don't I'm trying very hard not to have any Twitter, Facebook, anything on my web I don't want any tracking on my website. So, like, I'm not gonna give Instagram a free ride by embedding an Instagram URL into my website and letting them so if I just pop the Cloudinary URL in front of it, solves both problems. It can resize them, and it strips the actual, Instagram, Facebook from being embedded on my website.

Nice. Yeah. That's a good idea. Yeah. Okay. So next question here is from Andrew. Andrew says, what kind of CSS pre or post processors do you use? What are the pros and cons for a preprocessor SaaS, a CSS less, and the postprocessor as in post CSS? So these things, these tools are largely tools to modify how you write CSS. If you've never used the CSS preprocessor, what it basically does is it gives you some additional features that you didn't have within CSS, such as nesting variables, functions, mix ins, and a whole bunch more, all that fun stuff.

Post processes are interesting because what they can do is really just they augment the way you write CSS. So it can give you, like, superpowers ESLint CSS even as far as, like, changing property names and things like that. They're all really interesting. Now what do I use? I personally if I were to say what's my favorite CSS preprocessor, we've discussed this before, it's stylus.

But stylus isn't used to hold on anymore, or at least a ton of people aren't using stylus right now.

So I'm currently running Sass on level up tutorials right Node, believe it or not. It just sort of dropped it in there a couple months ago just for fun, because I was having issues with the global styles in styled components.

And so Yeah. I decided to do my global styles in SaaS rather than in styled components, just because. So, what are the different preprocessors? Those are the different preprocessors.

Sass itself, s a s s, is sort of a weird syntax that not a lot of people used. It was sort of Ruby inspired. There wasn't there was like a very, what do they call that when it's form it's like format based when you have, like, tabs and stuff like that rather than the brackets? Oh, yeah. It's, like, based on indentation. Yeah. You don't see it used a whole lot. I would just probably ignore that for now. SCSS is basically the CSS syntax with some additional features.

Less is basically SaaS with less features. That's my understanding of of of Less. It's basically SaaS with less features. It's totally caught up by now. I don't think that there are any features that Less is lacking, but it's Sanity? Community? For yeah. It JS. That's that's what it JS. It's that for the longest time, SaaS was more had more features. And that's why everybody sort of gravitated towards

SaaS, except for there's always, like, a weird like, I feel like all the all the Laravel developers all went for Less for some reason. The designer crowd went into Less because Bootstrap initially started using Less. Oh, yeah. They it was really easy to get up and going with Less because you could just drop in a script, and it would do it live rather rather than preprocessing it actually,

like, rather than compiling it. And that compile step, I think, threw a lot of people who weren't good at command line off or have build processes. Yeah. That was a weird thing. That was, like, the 1st time we ever had a build step in our website. It was. Yeah. And for people to have to, like, do that, it was a it was an odd thing. I remember, like, people would edit the CSS, and I'd be like, no. Don't. Like, you have to edit the source. It's gonna get overwritten.

I had a client once. This is a funny story. I had a client once where, I used I actually used Wes in PHP World in my WordPress because there was, like, a WordPress.

Sorry. There was a PHP library for compiling less. So I just did it. I said, if in the header, I just said, if if you if the admin is logged in, then just regenerate the thing as I'm loading this page. Oh. And, it worked great, and except that, like, I, like, deployed a client site, And they were like, I just keep changing the CSS, and I refresh the page, and my edits are gone. And they just like, I wasted 3 hours on this. I could not figure it out. I'm like, oh, what's happening is that, we're compiling

this on the fly. I obviously changed to more of, like, a gulp workflow after that, but I thought that was pretty funny. That is funny. Okay. So which what's what are the pros and cons? Well, honestly, I think JS a general blanket rule, if you're using a preprocessor, SCSS is probably the Wes you're gonna wanna use in twenty twenty Mhmm. Just because of the community, just because of the resources, just because the amount of people using it. As far as post CSS goes, I do love post CSS, and that's probably what I would pick if I was picking one of these even though I did pick Sass, I guess. Post CSS is really great. There's just a lot of cool stuff going on with it. Personally, I'm using styled components for all of that stuff anyway, so I'm not really using any of these. But as a general rule, if I'm picking anything, I'm gonna just pick SCSS.

Yeah. I I reach for post CSS. My own my own web my own, like, course platform is in Stylus, which I love. I'm sort of sad that it's it's going away, but I'm not that sad because, like, I like all of these things, and and people are really opinionated about it, but, but, like, it's not a big deal for me to switch from from 1 to another, even from project to project.

I would reach for post CSS myself because, like, I'm trying to think, like, what are the things that I still wanna use that aren't in just regular CSS, and that's nesting that's coming.

Advanced calculations, you see, we do have calc function, and color functions are gonna be a big one once we get those. And those are all things that will be coming to CSS one day. So I just like to keep it as close to regular and feature CSS as as possible. That's why I reached her post CSS. Yeah. Post CSS.

Alright. Wow. Those are those are just we're just 2 questions in. Those are some good ones. I like that a lot.

Next Node is from Graham.

What are the most effective ways to share a project on the Internet and get feedback? I'm in a phase right now where I'm building loads of new web things in React and JavaScript, but the only place I can share them is my Twitter where only, like, 3 people see them.

Oh, Graham, buddy.

Oh, so it's sad.

Oh, we're oh, that that's a good question. I think, the best place right now to post them is on Reddit. Like, there's Reddit our web dev, Reddit, learn JavaScript, Reddit what are the there's a couple other subreddits that are dedicated to that.

And then, also, I find and I get tagged in these all day long. It's the hashtag a 100 days of code. Yeah. Those get those get shared. Yeah. Yeah. Or at code newbies. I I get tagged in them, like, probably 6 or 7 times a day because people are taking my course as part of it. And I'm always surprised at how much interaction, like, a a Twitter account that was made 6 months ago and has 20 followers, how much traction that gets. Because people are following the hashtag, and they're following Node newbies on Twitter or doing the code newbies q and a. Once a week, they have a q and a, And I think those are just 3 great ways to to find a community of people who can give you feedback. And, especially, like, I find it super valuable feedback because often these people are just, like, 6 months a year ahead of you, and I find that feedback to be just as valuable as some 15 year old, or 15 year veteran of web development. 15 year old veteran. Yeah. 15 year old veteran of web development.

No. That's good. Yeah. I I I think the the keyword that you're gonna be looking for with any of this stuff is community. Find a community to share this stuff with. Yeah. Like you mentioned, those hashtags are great.

We have a level up tutorials Discord. The link is in the footer of level up tutorials Scott, and people share stuff there all the time, get feedback, share tips, and and talk about stuff like that. So find a community of like minded developers who are working on stuff and and just share with them. And like you said, I think Reddit is a great place for that specifically because of those things.

So okay. Next question is from Ted Lee.

What are your thoughts on classes in JavaScript? Do we still need them in 2020, or has functional programming paradigm made them largely unnecessary? Does the answer change based on the size of the project or the team? Okay.

Do we still need them? Node is an interesting work. No. You don't need them.

Some people like them. Some people prefer them. Some people prefer the OOP, object oriented programming, not of things. I personally prefer functional programming myself.

And since moving to React Hooks for my entire application, I have not touched classes.

Classes were the thing that I used in React, and that was pretty much the time that I used them.

Now not to say that I'm not doing a whole lot of JavaScript work outside of React, Vue, or Svelte, but I don't know. I I don't you don't need anything, and I know I don't wanna get too hung up on the need. You don't need anything. You can do everything with functions, whatever. Some people just like it, and some people like the object oriented programming side of things. Not to mention, classes are pretty brand new in the scheme of things.

And even though they are just syntactical sugar over how things work already in JavaScript, I don't know. I I I mean, I don't have any strong feelings on this one way or another. I think classes are fine. I had no problem working in classes, but I probably prefer functional programming overall.

Yeah. I I I've told the story before, but I once ran a, a poll on my Twitter. It says, do you use classes in JavaScript? And there was a sign, like, 5,000 people answered, and it was literally half and half. So don't let any but this is such a divisive topic. Yeah. It is. Don't let anybody tell you either ways. I think you probably will make that decision based on your team, especially, like, there's developers that come from other languages that are just classes to the grave.

And coming to JavaScript, although classes don't necessarily work the same way as they do in, like, a Java or something like that, it's just a they just write better code because that's the that's the way they think, and there's absolutely nothing wrong about that. You probably in our little circles of communities, you'll probably hear a little bit more, Now you don't need classes because the whole React JavaScript world right now is very hot on, like Scott said, like, functional programming instead. So that's why. So I don't know. Try them out. If if you like them, go for them. But it's it's not necessarily something you need, I don't think.

Yeah. Cool.

Is there something you would need for your JavaScript, though, Scott? Anything you can think of?

The yeah. Well, I mean, I'd be I Node, what do I need? I need comments.

I need,

I'll start the comments. That's another I need console logs. Divisive topic. I need,

I need decorators. I need all no. I actually need Sanity to keep track of my bugs. And when I say I need it, I literally need it because Sanity lets me know of all of my errors and exceptions that I can track, tie them to releases, and catalog them. Now Sentry, which you're gonna wanna check out at Sanity dot iocouponcodetastytreat, all lowercase, all one word, you're gonna wanna try out Sentry because let me tell you, Sentry has been around the block for a little bit, and they know exactly what people want to see. In fact, I just deployed a new version of my site on Friday, which, you know, you're not supposed to do. But if you're doing it on Friday, you better have some error and exception handling tools. And guess what? I see that I fixed a bug in my API, but I'm also seeing that I have seen an increased amount of front end errors.

Unfortunately, these errors are, happening to users on the site, and they're not big things. We have a a resizer observer loop that I gotta take care of, and this looks like some small stuff here and there. But it allows me I mean, I'm pulling this up right now. I can look at my own error log. I can click on one of these errors, and I can say, oh, yeah. This thing this thing right here, don't worry about this thing. This error, this is just a customer who got a credit card decline. That's not an actual error. Let me go ahead and click ignore, and now no longer gonna see that message. So, Sentry is a great way to keep track of all of the things that are happening on your site and what users are seeing or feeling while they're using your application. So head on over to century at century Scott I o. Use the coupon code taste treat, all lowercase, all one word. Get 2 months for free.

Man, I've got a before we end the century ad thing, I got a story. I I did my nightmare, which is I broke my checkout the other day.

Yay. I deployed some some new features to the checkout, and, something happened where the compile step didn't proper the didn't work properly, and I deployed the thing.

And I was freaking out because I was getting all these, like like, obtuse emails from people being like, hey. I'm trying to pay you money, and it's not working.

And it it was like, I need this info quick. I can't, like, email them and tell them to give me their console. So I just hopped into my Sentry, and I found the error that was happening, and I was able to fix it nice and quickly and get everything working. So I was like, oh, thank goodness I had that collecting the errors instead of

waiting for emails to come in Seriously? What went wrong. Yeah. Yeah. Thank goodness. And that's really where it really excels.

Okay. So next question is from Jonathan Beale.

Jonathan had a a note that saying his last name was impossible to mispronounce, and I challenged him on that. So, Jonathan Beall, aka Jonathan Bell here, he says, does Wes 2020 have Yarn, question Yarn? Also, is Wes 2020 a real spec or just a term people are using? Okay. So the Wes 2020 thing based on ES whatever, this JS all changed from how it used to be. You'll you'll all remember that, when ES was at ES 6 or ES 5 at this point, man, it's been so long. I'm, like, tripping ES 6. Right? Yes. When letting Scott came, yeah, that was ES 6. ES 6 came out, and it was like a a big deal that it was like, oh, this is Wes 6. This is the 6th version of ECMAScript.

And, since then, what happened was because there hadn't been any sort of major updates until Wes 6 had happened, it was, like, the the biggest update since 2011.

That was like Yarn. Yeah. It was years. Right? So, because like, 5 years before something new came to JavaScript before that. Right. So,

people were were sort of like, okay. This is the Wes 6, but then the very next year, ES 7. And and so, like, the the way it's changed is now is that there's a new version of ECMAScript every single year. So e s seven was e s 2016.

E s 8 was twenty seventeen. But the whole idea is that they wanted to prevent it from, you know, eventually being e s Wes, and they just decided to Yeah. Say, alright. It's officially going by the year Node, so there's going to be a new addition of JavaScript based on each year. In fact, Wes 2019, you know, brought things like, flat map

and, some other things. I'm looking at the Wikipedia right here. I forget every year. Yeah. There's there's always just, like, a handful, like, 2 or 3 Right? Things. It's it's Scott like EA 6. It's like, oh my gosh. Make a course about it. You know? Now it's just like, oh, those are a handful of handy little things. Right. So a lot of little things popped up here and there, and Wes 2020

is just the next iteration.

Right? It's the next yearly iteration.

And, does it have var? Yeah. Of course, it has var. They're not removing things from the language.

So, yeah, Yarn, let, const, they're they're still the gang's all still here. The sign a Wes I get a lot about with my ESX course is that these are not, like, separate versions of JavaScript.

Like, you were to run PHP 6, and then all of a sudden you have these these new versions of JavaScript. So JavaScript just continually adds new features and it doesn't take away I don't think no. It doesn't take away older features. The the only exception to that is, when we got use strict.

Use strict was a way for you to Node that your document was written in such a way, and in that case, it it did take away, some features, which is pretty pretty nifty that they did that. So do we still have it? Absolutely. Is it still is it is it a thing? Absolutely. We have, like, probably a couple shows that say JS var dead in in the title.

It the var is just another way to declare a variable.

And like classes, there's gonna be opinions all over the place.

Although, I heard a awesome thing on Twitter the other day from my buddy, Connor, who I think works at Slack, and they say he said, on his team, they say, Scott still you can't.

I like that. Yeah. Yeah. But that that's just our opinions. Right? Some people use let by default or always use let because const is not really immutable.

So, pick whatever you like and and go ahead and use it. Don't let anyone tell you otherwise.

Yeah.

Next question is from Jacob c.

Have you tried GQLS? It's atgqules.dev.

A GraphQL client alternative to something like Apollo ESLint. Very interesting idea for clean and maintainable code. Didn't we talk about this in the last podcast?

We've talked about it. I mentioned it to you. You looked at it for the 1st time. So this question JS asking, have we tried it? Did you try it yet? I have not tried it, and I'm gonna tell you why I haven't tried it, because it doesn't support all of the functions and features that I would need it to. Right now, it's just queries, and you need a I think my understanding of it is that you need a Webpack set up. So I have not tried it. I have not used it, but I am very keen on trying it eventually, especially once they get at least mutations. And I don't need subscriptions, but I can't think of a project that I'm using that's just straight queries with no mutations right now. So I'm gonna need those mutations at least some way. I don't know how they do it, and I don't really want to run this side by side with Apollo or something.

So I'm just gonna keep an eye on it and wait until it's a little bit more full featured, but it's one of these projects that I really have my eye on because, to me, it's just fantastic looking.

I'm I'm looking at the docs for the cache right now because that's that's a huge feature of Apollo is is the cache.

And the docs for the cache say, the inbuilt cache automatically caches everything for you.

Yes.

It says updating the cache to do. So, obviously, it's it's early days for this type of thing. I would probably sit on your hands for 6 months or so while they they figure this out, but definitely a contender for the future.

Cool.

So next question is from Papa Hub.

Papa Hub asks, what are the main differences between working in a software agency and a software product company? Pros and cons of each. Now I have not worked in a software product company, but I have worked at a software agency.

Now an agency is typically going to be an independent company that has many different clients or sometimes even just like 1 big client, but it's independent from the the, essentially, the product that's being created. You're creating the these works for other people, essentially.

And so, typically, the way it works in an agency is that there's, like, a project available. Let's say, here's an example.

You have a client. I'm just gonna use ford ford. Right? Fordford.com. Node.

I did. I don't I don't have personal experience with this one, at all or anything. But let's say there's a a ESLint like this, and they have a a job that needs to get done. They say, okay. We need a website. We need this. And, typically, there's, like, some sort of a bidding process, and companies will bid for those projects. You'll get the project. You'll complete it by a certain timeline. You'll push it out, and you'll either maintain it for a little while with some sort of a contract to maintain, or you'll never see it again. Where with a product based company, you are working on the product, and you are constantly working essentially on the same thing. Right, 1 piece of product or software. Now the pros and cons are oh, there's a lot of pros and cons here. The it's it's very interesting because with a product company, you're working in the same code base all the time, which can either be exciting, can be great if you love ownership of things like that, or it can be monotonous and boring if you hate the code base. There could be a lot of different things there if around the code itself, where with an agency, if you hate the code base, guess what? You get a new one next month or or, you know, you might have to see it very often. So there's definitely a little bit of, me, personally, I liked working at an agency because I liked, you know, having something new to try every single month because it gave me an excuse to try out some new technologies.

That said, as the owner of a business, I guess I no. I said I I don't work at a software company, but that's actually not true. I own a software company. So I have been working on leveluptutorials.com for, like, a 1000000000 years now since 2012.

And I have I had an ownership of that project, and I haven't gotten bored of it, but I am the decision maker. I can make all the decisions, and that's probably a different space than somebody who is a junior or somebody who JS, you know, maybe a senior developer, not like a CTO or something.

Now there's also some financial stuff here that I think needs to be thought of because I've worked at an agency that was, like, struggling for cash at some point. You know, you there's like this, like, delicate dance of projects coming in, and you wanna have your schedule filled, but you don't wanna have it overfilled, or else you're gonna be, like, cramming for overtime. And you don't wanna have it underfilled, or else you're not gonna have any money coming in the door. There was, like, a time where we were there was, like, a recession, and we were going through a major crunch. And we all did take 25% pay cuts just to keep the doors open of the studio, and it was really rough. It demoralized people and made you not wanna do anything. You'd come to work, and you wouldn't have any projects to work on. So there there is definitely, like, pros and cons here and there. The financial side of the product company is that if your code sucks, then you could potentially lose money that way.

So there's there's a lot of, pros and cons to think about here in terms of both how you like working on code as well as job stability and financials. It really depends.

I think the the only thing I'll add because what Scott said is bang on is that I can always tell when I am talking with somebody, whether it's on Twitter or at a conference who only works on 1 product because they often find it very hard to understand why you might do something that specific way or, what this tool would be useful for because they have their product, and they have their set of problems, and that's their their entire world. Especially, you see this, like, boot camp students who've been at a company for 2 years. It's like, they only know this one product. Whereas, like, Scott and I, we're spinning up new projects, trying new stuff. You're working at an agency. You're starting new projects every couple months. If you're you're building apps for clients, you're you're tackling it in different ways, and that's not great for, like like, code livability, like, how long something lives, but you certainly are tackling things in all kinds of of different ways. And I think that makes you a bit of bit of a more well rounded developer. Totally. Yeah.

Next question.

Ransan from Discord. Is this from your Discord, Scott? Yes. Alright. I'll read it as I'm as if I'm asking you.

Advice for having a static blog with minimal moving parts. Hey. I'm building a static blog with minimal moving parts right now. Yep. I used to have a static blog, and I eventually got sick of it sick of touching it because instead of writing content, I often got stuck keeping up with all the dependencies involved. Absolutely feel you there, brother. It's like if you take a break on from building my website on the weekend, and you start it up on Monday, and it's like, oh, 400 Sanity warnings. So as long as you keep it under a 100 security warnings, you're good. So keep going with the question. My old stack consisted of Jigsaw, server side generated Laravel, Vue. Js, and a bunch of plugins, Balmain CSS, Netlify CMS.

As you can see, the decisions are definitely not to blame. By the way, in the middle of question, I'm gonna cut in again. Do you see Gatsby is making a CMS? Say what? Called it they've they put out, like, they put together a GitHub issue. It's in very early planning days, but they are making I think they're calling Gatsby admin,

and told you. I I called it. Is it, like, a re is it r an RFC an RFC?

Yeah. Request for comments. Is that what that means? It is. Okay. So pretty cool. We'll we'll talk about that when it comes. Anyways, back to the question again.

The obvious step would be, one, to drop Netlify CMS because I'm good with markdown anyway, and 2, not relay on a CSS framework.

I'm considering switching to a so going full JS would be ideal.

Interesting.

I think, yes, you should drop it depends if you if you need all of these CSS frameworks. You likely don't. Go ahead and drop that.

Drop as many dependencies as you can because like you said, you're you're gonna spend your whole day updating the content.

If you're if you're a developer, yeah, absolutely Node to markdown.

We've talked about that a a number of times on this podcast, how it's good for developers' websites.

And it sounds like, you are the perfect use case for Vue because like, what's the what's the Vue static site generator?

Gridsum.

Gridsum. Check out Gridsum because, it seems like people who love Laravel also love Vue. It's it's sorta in the same vein. So, check that out. I think you have a pretty good answer here already. Yeah. There is a ton of static site generators.

So I'm I'm gonna post a link in the show notes here for What about Eleventy? Right. For static gen .com.

And this gives you a giant and I'm talking giant list of static say generators that tells you what it's built with. So, okay, it's built with JavaScript.

It uses Vue or uses Svelte. It uses React, whatever, and how many GitHub stars it has, how many issues it has open, how many pull requests.

It's really cool.

Love love love this Scott, this site. Was this put together by Netlify? I feel like this was.

It's been around forever.

Yes. Site gen is is hosted and maintained by Netlify.

So this is a really cool place to find out about new static site generators, things that you can use and maybe some that you haven't heard about, some that you have. Maybe find the perfect one for you. We could have, like, a static site generator dating service Wes you'd you'd give us all your needs and wants, and then we return to you the perfect static site generator for you. But, no, head over to static gen.com.

Also, one thing that people will not stop suggesting to me is Hugo.

Yep. Yeah. Hugo's big. Anytime I start to say the g of Gatsby, there's somebody, like, knocks on my door, and they're like, hello. Have you ever heard of Hugo? Yep. So, maybe check that one out as well. We'll check it out. So Gatsby has

43 1,000 stars on GitHub. 4517, and Hugo has 43.

Woah. 148.

So just ever so slightly less stars just ever so slightly, but both of them seem to be very popular. So, not bad choices either way.

Okay. Next question is from Jigs. Hey, Jigs. I don't know if you know anything about breaking, but there is a famous b Bos. Well, not really a famous name, Jigs, who's good. So Google, Jigs, b boy. He's pretty good. So the question JS, micro front ends, is this the solution to rewriting legacy components? And let me tell you, micro front ends is very interesting to me. And I don't What is a micro front end? Micro front end is breaking up your front end into different front end libraries. You could use a little bit of your site in React, a little bit to say your view, a little bit of your site in Svelte, or maybe they're just different little components of your application and in different versions of React. So it's basically breaking up your front end into smaller micro chunks. You can think of it as, like, the serverless of front end. They took the idea of, like, alright. You break up your your thing into different things, and now you can make decisions on one part of your application that don't push through to the entire application.

So, yeah, I am not sold on my current friends.

I don't understand the benefit.

I understand that they could be useful in this the situation where you have maybe, like, some of your site is in backbone. You wanna move over part of it to react or something or part of it to Svelte.

Micro front ends. It's an interesting concept to me, but what I haven't seen is I haven't seen the killer example. I haven't seen somebody say, okay, this is the easy, awesome my girlfriend and set up. This is how it just works. It all seems very sort of taped together to me JS the best way I can describe it. Do you have thoughts on that? Like I said, I can't imagine doing this for any any reason other than Yeah. Rewriting legacy stuff, but yeah.

That seems like a a a SHIT show to me. Go back to the episode where we talked about Cloudflare Workers, where somebody sent me a DM how they were migrating their, legacy website over to React, and they were doing it component by component.

And they were using Cloudflare Worker to basically stitch the old they would just take the old website, and then they would just start popping in the new pieces as they were finished. And then eventually, you've popped every piece, and there's no more legacy pieces to Pop in pieces.

Think that Chris had a song about popping pieces.

Really? So just start popping pieces.

I think that that was probably a good way. I don't know. Like, you send us your tweets. How do you do big rewrites like this? Maybe we should even have somebody on the show who went through a a large rewrite like that because, like, I think about, like, even, like, the government of Canada's website. Like, how would they ever switch over when you've got Yeah. You've got URLs to maintain? You've got hundreds of thousands of pea pays pages of important information? And, like, how do you how do you switch over from something like that? That's a question I have.

Yeah. It seems like not a lot of fun. I'll just say that.

But what does seem like well, also does not seem like a lot of fun, but could be fun if you use the right product JS keeping track of your books and invoices, Ed. So, that's why we recommend FreshBooks because it makes it not not fun.

No.

Accounting, keeping expenses, tracking your hours, that's Node thing I hate doing. All of that stuff is not fun, and FreshBooks makes it as quick and as painless as possible so you can get back to doing fun stuff. So you're trying to track your hours, you pop ESLint FreshBooks. You can use a timer on their, on the app if you want. If you have an expense, you snap a photo of the receipt, input how much it has. In Canada, I put how much HST was included on that. It's just a great way to manage all of finances around your small business. Check it out. Freshbooks.comforward/ syntax. Make sure you use syntax in the how did you hear about us section. Thanks so much to FreshBooks for sponsoring.

Cool. Next question we have from oh, this is gonna be a tough one. Got you all the.

Next question is from Betya Betya Kent Nouncineum can't Sanity nouns.

I feel like I'm being tricked.

It's like if I'm saying like, that you know, that, like, will you marry me in that commercial? Yeah. They were in, like, headbands. Anyways, thank you, Bhatia.

Hi. I'm relatively new to Wes development, and I feel like it's very difficult to catch up with JavaScript.

Scott you right there. It is very hard. We all feel like that.

Next question.

It seems like whenever I try to contribute in open source, I can't figure out the code because they're using newer and presumably better ways of doing things.

How can I get up to date with everything that's going on in the JavaScript world? Also, at what point should I start learning a front end framework? I love your podcast and have listened to almost the entire backlog, and I found you 3 weeks ago. Wow.

Wait.

So 3 weeks ago and there's this is episode 244.

So if half of those are an hour long, that's, like, 70 hours of content that you listen to. Good job.

Yeah. So how how do you how do you keep up to date? That's quite honestly one of the the hopes of this podcast is that you don't necessarily have to to keep up with absolutely everything because it's it's impossible.

Impulse. What you need to do is you need to first, it sounds like you're learning the area. So whether that JS, like, a front end framework, sounds like you're in a good spot for picking up a front end framework, whether that's Svelte or React or Vue. You can likely make your decision because you've listened to every podcast here. And just just focus on that. Just focus on on getting really good. I'll use React, on React.

And then and then you can start to expand your horizons. And once you're comfortable with that, either add on to that, maybe look into a little bit of serverless function, maybe look into a styling framework, something like that, or switch to another framework and and see how you you like that thing. So, really, that and copious amounts of time, being being at this for I don't know. Like, how long have you been a web developer, Scott? Like I don't know. 10, 15 years? Longer. Longer. A long time. We've been at this for a long time, and Scott and I are only really confident in a slim section of the JavaScript world. And then we also know that we have good good

JavaScript skills, and we know that we'd be able to pick up other frameworks should we want to or need to. Yeah. And that's really the the key JS that you can't. So don't don't feel bad about that. You can't. There's so many times I open up those open source projects, and I'm like, cool. Why are they doing this this way? I don't even know. I'm gonna leave, because I'm uncomfortable.

But, no, I I think there's just too many things here, whether it's new techniques or whatever. But sometimes I think it depends on what your state of mind is. Right now, if you look at an open source project and you don't have the time to, really dive in, you could say, alright. See you later.

But if you are in a curious mood, I found that open source code is some of the best ways to learn new techniques, new skills, and dive into how other people do things. Other people do things JS not always better. Sometimes it's just different.

I was wanting to take a project that existed, and I was going to adapt most of the code to my own functionality.

And they were using, like so okay. But to be less vague about this, there was a reactive video player that exists that's open source, and I needed a video player, but but I didn't wanna write mine from scratch entirely, or at least I wasn't quite sure exactly everything I needed. So I started diving into this one, and I found it was really neat.

But they were using Redux for a video player. And I was just like, why do you need an action to be called to do this, to do that, to do that just to do play on a video player? So I Oh my gosh. Yeah. I was just thinking, like, am I missing something, or why is this so overengineered? And it just just did a different approach. Honestly, I I would say it's Wes for, but, it's a different approach, and it's totally valid as long as it works. So, you know, don't always feel like everybody's approach is better, but it could be an interesting way to learn something sometimes.

Okay. Next question is from Paige Niederinghaus.

Nailed it. Thank you, Paige, for the No. Pronunciation guide.

The phonetic. Yeah. She didn't give us any no. She didn't. I I pulled that out. I I I'm a good reader. No. Okay. Okay. So, hey, Wes and Scott. Big fan of your podcast. Keep up the great work. Thank you, Paige.

I had a question about custom hooks in React. My team and I are starting to write pretty complicated custom hooks, gathering data from a number of different endpoints and pulling certain endpoints on a continuous interval timer before returning it to the component that needs the data.

Since this is the case, some hooks have gotten fairly large with multiple functions inside of them getting called to get manipulate all of the data, multiple hooks using the same functions to get slightly different data, is it the best practice to keep all of the hooks together in 1 file, or should we break the hooks into separate files and move the helper functions into another file just to have 1 hook per file? Oh, so I just did a course on custom hooks. I'm Scott, by all means, the authority on this subject, but I have done quite a bit of work in custom hooks. And the way I see it is I create custom hooks. And then if I notice that it's getting difficult to parse, difficult to understand, I might break some of that functionality into another custom hook and use that custom hook within a custom hook, custom exception.

You know, I've I've used a custom hook within a custom hook within a custom hook before or a context within a custom hook and whatever, and I found that keeping things organized is occasionally difficult. But if you can break things out into, you know, what makes sense into their chunks their their usable chunks, then that's fine. And just like React components, I find, I find custom hooks to be very analogous to React components, but just for functionality. Right? You could have a giant giant custom hook, but it makes more sense for all that stuff to be together based on its functionality. Just like you could have a giant React component that makes sense for it all to be together, or you can make many smaller ones that all work in coordination.

And both of those approaches are valid. It all just depends on the use case, and some of it is going to come down to your personal experience.

So there's no hard and fast rules that say, okay. This is going to need to be, custom hook here, and there's another one here. But I have used a custom hook within a custom hook within a custom hook, and sometimes that's perfect. And other times, I have a giant custom hook. So, again, it's all about experience. And just like just like you get the feel for when you should break a new React component, you will get the feel for when you need more custom hooks.

Yeah. I'll speak to, like, should they go in their own files? I'll just tell you what I do. So when I write a custom hook, it's generally I'm working on a component, and I go, oh, I need to do something.

So I'm what I do is I just go above that component and I write the hook. Yep. Then I will often find myself needing that hook in, another component. And if that's the case, I move it out of that component's file, and into its own file. I do the same thing for styles.

I'll often write the styles in the same file as a component. And then as I need to reuse that, I will throw it into its own file because it's now used by multiple different files.

And then the third thing is you said you have a lot of utils that are used inside the hooks.

Absolutely. Put those into their own file.

That makes testing those utilities very easy because they're nice clean exported functions from that file.

And it's not if it's not something that is entirely related to that hook and it's used, again, in multiple functions, then put it in in its own file. So on a as needed basis, but, absolutely, don't feel afraid to put them in their their own files.

Yeah. I have a whole folder with all of my custom hooks if they're used globally throughout the site, and it JS, like, 1 hook per file. And, if I do need a custom hook that's, like, just for a specific section on my website, I'll I'll throw it in that feature folder just as, like, here's the like, let's say I have the checkout, and I have a custom hook that's used checkout that used checkout hook is only being used for the checkout that things go on right in that checkout feature folder rather than my general hooks folder, and it's just gonna be use checkout Scott t s. So, yeah, that's largely how I think about it.

Next question we have here from Jared. Any tips for navigating projects with bad project managers? Working with a nontechnical agency project manager is really difficult to plan and allocate time to ensure all the projects are done on time, on budget, and done well.

It's important to me to maintain an optimistic attitude in the organization, but sometimes I'd love to just hit them with the old piece out and go smoke smoke some pork butt. Let me tell you, as someone who quite recent quite frequently peaces out and goes to smoke some pork, but let me tell you, that is a good a good way of life.

Wonder if you have any good experience. Sometimes you gotta go out and smoke some pork butt, but that means something different here in Colorado.

Everything in Colorado something a little different.

Wondering if you guys have any good experience on managing these types of projects.

Yes. These these types of projects are so draining because, not only are you trying to technically solve the problems, you are playing the role of trying to budget time and and maybe even money in that case. And if you don't really know if it's unclear as to what needs to be done or if the project is messy or or all this the Vercel, like, I've talked to, like, working with project managers in the past where they send you emails at all hours. They love meetings, love having calls, things like that, and that just just drains you mentally and pulls you away from from doing the work that you're supposed to be doing. So how do you do it is you really have to train the project manager

that training a dog.

Yeah. You have to you'd if you hit them on the nose and say Node, Node. You you gotta you gotta train them that you are not like, it's very clear to you that you know how to how to gauge how much time it is if they supply you with the the right thing. So just letting them know up front, if you don't have all the information, if things are are messy, if you don't get stuff on time, if we have too many meetings, things like that, then then things need to to get pushed. So you almost have to be a bit aggressive, I would say, is is the word that you use for this type of thing because everyone wants to be Node, and like you said, you wanna be optimistic about these things. But in order for you to make it look like you did a good job, you need to be very aggressive with the type of person who you might be dealing with there.

Yeah. It's all a tough balance. It's funny. I'm gonna send this to my brother. He's he's recently gotten a job as a project manager Node, so, he he needs to to learn some of the stuff about working with developers because it's so funny. He he now talks about, like, developers. It's like he's never worked with developers. Before, he used to be logistics for truckers, so he's used to talking to truckers. And now he's talking to web developers. He's talking Scott I can't trust this developer in a meeting. I can't do this or this. And it's so funny to get the opposite side of the coin because I've worked with so many project managers, and the best project managers were the ones who really understood the timelines, let me do my thing, and knew when I was capable of meeting with the client myself or whatever. There are some, there are some project managers who are just super aloof, and and there's not a whole lot of things you can do because they are, at some agencies, they are the barrier between you and the client.

And if the client is unhappy with the time line and you have all of your stuff done, that's not going to look bad on you. That's going to look bad on the project manager. I had 1 project manager.

This project had been going on for several months, and they were just like, so what's the status of this project? And I said, I finished it 2 months ago, and I had told you. And I sent the email, and you asked me about it 2 weeks later, and I sent you the email saying it's finished. Here it is. And then they're like, okay, we'll set up the training now. And it's like, some project managers just don't get it. Sometimes sometimes they're just not good at their job. And you as long as you have the email chains and you have the the receipts to show that you're doing your job effectively, you know, just sometimes it's out of your hands. It depends on how much control you have over the situation and how much you're able to actually manipulate the, timelines and the the budgets and things like that. It it's sometimes, project managers are just not going to be there for you. So you just do your work, do it well, make sure you have the receipts, communicate effectively, and sometimes it's out of your hands after that. So, again, those are the those are the big keys. Communicate.

Have receipts. Do you work? Alright. Last question is from Steve Pulido.

Steve says, I'm committing often and early, but this means I end up writing the same vague commit messages over and over again.

I know the solution to the problem is to just be more verbose, but it's a difficult habit to break. Any advice? Okay. I have a simple way that I like to think about commit messages. For those of you who don't know, if you don't use Git, what Git is is a version tracking system that keeps track of all your files. You could think of it like, something that saves your your bacon in case, you know, the machine crashes or something. You have different versions. It also allows you to branch off different things, try new things, and and not worry about breaking your code.

So commit messages are a way to describe to everyone else, including yourself, your future self, what exactly this code contains.

So if your commits are vague, then that's telling me that you're not doing any code changes. Like, what is a commit message supposed to do? Again, it's supposed to tell you what the changes are. And so bug fixes is not a good commit message because it doesn't tell you what the code changes are.

If you have a GitHub issue, include that issue number as, hey. This fixes issue number blah Bos blah. Fixes issue Wes blank.

I like to describe these as, Wes like a Sanity starts with a verb in like a so fixes issue where user profile picture was upside down, adds a new image format to this. Blank does this to this, but it should never ever be something like bug fixes or updates updates, dependencies, whatever. None of those things are good commit messages because they don't tell you what the actual code changes.

The the most important things is describe what changed, your future self, your other developers. Everybody else will thank you for it.

My tip here is to squash your commits before you send a pull request to master or or merge into master. So, when I work on a team, my flow would be just commit, I don't know, like, a couple six six or so times a day or a couple times a day, and and be as good as you can, like you said, but it's a problem to to think about good commit messages every single time, especially when you're just doing the same thing, on 3 or 4 different commits. So what I would do is I would commit for the day, and then once I'm done a feature, I would squash those commits, which is just just Google whatever the command is for for squash, and that will open up a list of all of your commits, and you can cherry pick which ones you want to be squashed into the other Node, and then you can write a new commit message for all of that. That's very descriptive. You include numbers or ticket numbers, things like that.

And then that's all done on your own branch. And then when you send your pro request, that goes through to as a nice single tidy commit. Oh.

Yes.

Just don't squash commits after you've pushed to master then then you get into rebase hell. It's awful. I've been there.

Yeah. Git hell is one of the worst kind of hell to be in.

Totally.

Let's move on to some sick picks. Do you have a sick pick, Scott?

Oh, I am stumped for a sick pick this week. I do not know.

So what I am going to sick pick is a YouTube channel that I have sick picked before in the past.

And, I think I've even maybe picked this really recently, but I I I still love this YouTube channel. I watch it all the time. So, this is the Gelsmarble runs for those of us who are needing some Oh, is it back? It's back. Yes. So, last time, last time my sick picked this, this YouTube channel conveniently Scott, like he accidentally deleted all of his videos or something, like, the day I sit there. I think he goofed it up himself. I think he he was How do you accidentally delete your entire YouTube channel? Trying to do something, and YouTube had to step in. And I don't know if Node had to recreate it or whatever. Either way, Gelsmarble runs is a YouTube channel where Vercel he races marbles. But he does it in a way that he pretends that they're like sports teams and that there's actual teams with he names them all. It's very cute. It's very fun, and it's very addicting. If you have if you're needing, like, sports in your life right now, which, you know, I I like sports. I'm a sports fan.

I put these on, and they're also very I mean, they're very, very kid friendly. They're very, innocent in in a lot of ways. So, they're fantastic.

They're a lot of fun to watch. And you know what? You end up becoming a fan of various marble teams, and then you end up hating other marble teams for no reason, just like you do in real sports. And so it's it's a it's a blast. I I highly recommend watching some of this. And if that sounds ridiculous to you, put on one of these videos. And, who knows? Maybe you'll just find yourself rooting for one of these marble teams.

I'm gonna sick pick a tool. Scott and I, Wes we sick pick tools for our weekend projects every now and then, and I am just getting done, with installing a bunch of pine paneling in, in a shed that I'm turning into an office.

And in order to install this stuff, you Node, like, a nail gun and a compressor, and that stuff's kind of expensive, especially because, like, I'm not I'm not gonna be using this all that often. Although, I don't know, a couple times a year, I have to go go borrow my dad's nail gun. So, now I have 1, and I bought this little kit that was dirt cheap, and I'm gonna tell you how to make it better. So this is hilariously who makes his hun Hyundai, Hyundai, the car company. Hyundai.

Hyundai. Hyundai. They had a commercial always Sanity. They had a commercial that Wes, like, Hyundai, like Sunday.

Hyundai. Oh, yeah. I always say Hyundai. Yeah. They had a commercial that tell you how to say it here in the States. So Hyundai. Hyundai. Hyundai. Okay. So they, I guess, make tools as Wes, and I bought this, like, dirt cheap little 2 gallon air compressor, and it comes with, a nail gun.

It's also a staple gun, and it has a bunch of fittings. And it was, like, $114 Canadian, which is, I don't know, like a ham Sanity, an American right now.

And I got it, and I turned it on. It started leaking. And I I I went to the reviews, and I'm like, oh, this is why people don't like this thing. So I just, like, took apart all the fittings, and I put the Teflon tape on it, which is what you're supposed to use on threads that have air or water, I think water, yeah, on them. So I took apart all the fittings. Teflon taped it. Put it put it back together. Thing worked amazingly well. I shot, like, 5,000 nails through it, and I only jammed up once.

So I thought for the price, it's obviously Scott, like, a professional tool.

But for the price, you can't even get a air compressor for how much I paid for this entire kit. Wow. So I was I was pretty impressed with it. It's the Hyundai h h c two g n k.

Wow.

Yeah.

Alright. Shamelessly plug all of my courses. Westboss.comforward/courses.

Use coupon code syntax for $10 off. Learn, use some JavaScript or some CSS or whatever it is you like to learn, during this downtime.

If you have downtime I don't have downtime. So

Yeah. I'm on a shamelessly plug level up tutorials.com, and, check it out. It's a lot of tutorials there, a lot of tutorials.

So I make a new tutorial series every single month. It's like a, video TypeScript, or it's like a magazine TypeScript, a new tutorial series every single month, And the latest one is on custom React Hooks. So if you're interested in learning all about custom React Hooks, head on over to level up tutorials.comforward/pro.

Sign up for the year and save 50% right now. So thank you so much for watching, and thank you so much for watching. That's why I say at the end of my YouTube videos. I just, like, went into total preprogram Node there. Oh, boy. There you go.

I won't know.

That's all I got.

Alright. Thanks so much for listening.

We will catch you on Monday.

Peace.

Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.