Potluck: Migrating to Typescript, Semver Explained, Accurate Timers and Countdowns

with me as not always, but for the the the first time in a regular episode is CJ. CJ, what's up, dude? Hello. Not much. I'm doing alright. I've got some big Canadian shoes to fill today, so, I'm gonna I'm gonna do my best, a.

Yeah. Me neither.

Yeah. No idea.

This is probably the worst question for me. I I left it on there because I think you have some good answers, but I actually don't read a lot of books.

And I think, like, my answer for this is if I can't get past the 1st chapter, I just stop reading it. So, like, there's stuff there hasn't really been anything that hasn't changed my life. But I do I listen to, like, a lot of, like, science fiction on, like, audiobooks and stuff like that. Right now, I'm actually listening to, The 3 Body Problem. Oh, cool. Yeah. Yeah. Haven't finished it yet, but it JS it is fascinating. But yeah. I'm interested in that. That's my main thing is yeah. If if if I'm not interested, I'm not gonna read the whole thing. I don't know. Yeah. Yeah. I feel that.

Nice. Yeah. So this next one comes from Electric Eli. And their question is, what are the fundamental web app development principles that beginners should know about when starting web app development. And they have in their ESLint authentication, test driven development, deployment.

Honestly, I don't think any of those things are at the top of my list for beginners. There's actually a whole lot more. Yeah. And, one of the things I think is most important is, like, really understanding the client server model. I come across so many beginners that just, like, don't really understand the difference between the client side and the server Node. And, being able to differentiate those, even if you don't do a lot of back end development, is huge, especially if you're working on a team that has back end developers, because you can at least better understand what their piece of the puzzle is. And then along those same lines is understanding that that same security model of back end versus front end. Because when you're working in front end code, that code gets shipped to the browser. So there's only certain things you you should do within that code because, at the end of the day, end users can technically look at the source code and see what's happening in there. So, really, understanding what's happening where I think is one of the most important things. Yeah. I have that as a big one too.

Yeah. And then another one I have is CLI basics. So, I I know there there are, like, GUI tools for, like, Git and stuff like that, but, especially in more modern front end web development, you're gonna come across a lot of build tools and scripts and things you have to run. So just being somewhat comfortable with the command line, I think, is pretty important. So just, like, basic commands like cd and ls and those kinds of things because you're gonna be running Node and Npm scripts and, like, maybe, like, a Vite build process or something like that. So, yeah, that's definitely at the top of my list as well. Yeah. If you wanna learn some of that, Wes has a, I believe, a free course, Command Line Power User. There's also I did a course a long time ago on the well, it's Wes LevelUp Tutorials at the time, but there it's on the, YouTube channel if you're watching on YouTube. So And another one I have that almost has, like, kind of, like, nothing to do with, like, writing code itself JS really just working on your your workflow and and how you work. So I'm a big proponent of, like, keyboard shortcuts, and just, like, working efficiently.

I think that's definitely something you should look at, like, especially if you're trying to mix things up when you're a beginner and you're learning is, like, you don't wanna just be writing code all the time. You can focus on your setup, focus on memorizing keyboard shortcuts, also, like, work on your, like, your work habits of, like, actually working for a little bit, taking breaks. Maybe you can try Pomodoros, those kinds of things.

a ton of support. So, that's kinda how I feel about it. I'm a little salty about it. Yeah. I don't have much insight more than really just, like, reading the blog post recently and kind of, like, seeing Chris' perspective on everything. But that's kinda my take on it. It was like, this just sucks because, like, CSS Tricks was awesome. Like, it Wes the definitive resource for, like, so many things. Like, anytime I wanted to know about Flexbox or CSS Grid, like, I would go to CSS Tricks for that. So it's it's really sad to, hear the story of of of DigitalOcean kind of taking over and not really doing much with it. Yeah. And it was really hard for us too when we announced

Alright. This next question comes from Mike, and it is, what advice would you give to someone finally looking to migrate an existing React project over to TypeScript? Any gotchas to keep an eye out for? Any linting tools to take advantage of? Should the work be done in a feature branch solely dedicated to the migration, or can it be done pnpm a more piecemeal manner? Any other advice? Thanks.

So I'll give my perspective on it first. And I think it depends on the size of the project and also, like, the number of people on the project. I would say if it's, like, a really big project that you can't just kind of, like, do all in Node go, one of the easiest things to do is just start 1 file at a time. So, one of the cool things about, like, even, like, working inside of Versus Code is you can get TypeScript support even inside of JavaScript files. So one of the first things you could do is just put a a slash slash t s dash check at the top of any JavaScript file, and then you're gonna start to get some type hints inside of that file. And then from there, you can start to change the file. So, like, go 1 file at a time. And you can basically make it so that, like, if you're working on a specific feature, now JS the time to also convert it over to TypeScript. Kind of, like, make it your process of any new feature. Also, make sure that you're shipping TypeScript code with it. So swap a JS file to a TS file or a JSX file to a TSX file, and then gradually fix the errors within that 1 feature within that 1 file. And I would also say that when you're early on in this process, keep your TS config settings, like, way less strict. So you should actually allow the any type and allow things like TS ignore and TS expect error, because you're gonna have an easier time of converting. Now, obviously, you wanna get to a point where you have, like, a stricter configuration and, like, you're really, like, writing the best TypeScript you can. But early on, you definitely want to be a little bit less strict so that you can make bigger strides in terms of, like, converting your code base. Yeah. I totally agree with all that. I

Definitely. I completely agree with I mean, like, so many people can get too too caught up in, like, fixing all of the errors and too caught up of in, like, trying to make, like like, the perfect TypeScript code base. But like you said, it really is, at its core, kind of just a linter. Like, it's gonna help you with a lot of problems. And I completely agree with Data First, because, honestly, that's where you're gonna get most of the benefit. Right? If you start describing your types and your objects, that's gonna flow through your code base. And and now you have a bunch of different places where you can, like, catch little errors, like, oh, well, you made a typo on a property Node, or, oh, this object is actually missing properties that were required. So, yeah, I I completely agree. Data first is a great approach, and, yeah, just go for it. Yeah. You know, it's funny because we Wes talked a little bit about this. I had, like, a TikTok. It was from a clip from one of the episodes of Syntax where it was like, we launched with TypeScript errors for the new Syntax site. And that was like,

some casting or some any or something. And I don't know if he wrote it. Maybe I wrote it. You can't blame it. Yeah. Yeah. I'll be able to find something where you could say this is like a patch on top of something, you know, just because that's just the way it is working in TypeScript sometimes. Yeah. Yeah. And I can just add to that, like, one of the experiences I had actually starting from scratch is just doing, like, a slow port. So I have several code bases that it's kinda just a mess of, like, copy pasted code. Like, it it works for what I need to, but I was trying to, like, more modernize that code base. And one thing I'm doing is just converting it to a monorepo 1 project at a time and, in the process, converting it to TypeScript, like 1 project and 1 file at a time. So I'll, add a new package to the monorepo.

I'll start to port over the Node, but anytime it's, like, not using TypeScript or it didn't have the exact right types, I'll spend the time making it work and and making it nice and pretty and using all the types that I can. I realized that not everyone has that luxury. Right? You can't always start from scratch. You can't always just, like, port everything over piecemeal, but it's it's a personal project. So I think it it depends on the size of the project. It depends on your scenario, but there's definitely a lot of ways to approach it.

I have done some timers and stuff, but I'm interested to hear what you have to say, CJ. Sure. Yeah. So I I I've, the way that I've approached it and, again, this is just my approach. I think the other thing about this is, like, what Tim has described, it'll probably work. I think it, when it comes down to accuracy, that's might where might be where there there are some kind of, like, holes in the plan. But let me tell you, I guess, how I would implement it and in some things about set interval and set time out, because what you may not realize is that with set interval and set time out, let's say you pass in 500 milliseconds.

That's only a minimum guarantee of when the the function will be called again. It's not that this function will be called in exactly 500 milliseconds.

So that's where you lose that accuracy. If you're saying set interval with with a 1000 milliseconds, it's at a minimum a 1000 milliseconds, but it might be 1,100 milliseconds or something like that. It all depends on, like, what's happening in your in your JavaScript codes. So that's important to note if you're using something like setInterval or setTimeout.

And so my advice is don't actually use either of those things. Basically, the the state or the source of truth here is potentially the start and end time of each of your timers. Right? So you might have a a start time or that you set as, like, the date when that specific timer started, and then you maybe have another property that's, like, duration total duration in milliseconds. And so that's, like, kind of, like, your source of truth. And then now that's it's completely accurate because no no matter how often a set interval or a set time out runs, you can always do the maths to figure out when should that timer actually end. So, yeah, keep your state that way. Like, have a start time or an end time or a timer duration in milliseconds.

And then you also just have a single tick function. So the the idea with this is it gets called once every 100 milliseconds or once every 200 milliseconds, and that looks at the state of all of your timers. The other idea with implementing it this way is you have way less things to manage. Right? So let's say you have, like, 10 timers and they were all using set Vercel. Now you have 10 different functions that are all potentially firing off at different times. But if you have a single tick function that kind of, like, looks through your state of timers and determines, alright, when did that timer start, when is it supposed to end, and then, like, update your store state accordingly, it's gonna be much easier to manage. And the other thought with that JS, actually, don't use a set interval for that. Just use a set time out. So you set time out in 200 milliseconds. Your tick function runs. It looks through your state to determine which timers are done, how much time does each timer have left, and then it calls itself in 200 milliseconds with a set time out.

This next question comes from LA Drinker, and, their question is, are you listening to podcasts? Which ones? So first up, Syntax. I listen to Syntax. K. Yeah. Me too. Listen to Syntax before I worked here and and now that I do as well. But I I like some of the podcasts that come from WNYC. So there's This American Life and RadioLab.

I'll almost always just download some of those episodes if I'm going on, like, a flight or, like, a long drive or something like that. This American Life is literally just, like, slice of life stories.

Radiolav, also kind of like slice of life, but they do a lot of audio production. So there's, like, really interesting, like, music they'll add that kind of, like, it adds to the audio storytelling element.

And then, I like a podcast called, Darknet Diaries. Have you ever listened?

Nice. Oh, he's featured on the syntax one, so we're we're tight. But, yeah, that that one's so if you haven't heard of it, it's all about, like, hacking and everything involved with hacking. Not not not only, like, cybersecurity, but also, like, physical penetration testing. And so he'll get guests Jack will get guests on there that will kind of, like, describe and talk about their their stories and exploits of, like, breaking into buildings, like, legally because they were hired to do so, and then also just general, like, hacking stories. So, yeah, that one's super entertaining. I also listened to Song Exploder. I haven't listened more recently, but this one's cool because they will get the actual musicians and producers for songs and then kind of break down what actually happened, in the song. And there was actually a a Netflix series that launched that was, like, a a companion to the audio podcast, but the audio podcast is really cool.

And then a couple more.

I listened to a podcast called Ear Biscuits. It's from, Rhett and Link, some of, like, the OG YouTubers.

And their tagline is 2 lifelong friends talk about life for a long time. So it's literally just them talking about random things, but I'm a big fan of the, Good Mythical Morning, so I enjoy that. And then the last 1 is WTF with Marc Maron. So I started listening a long time ago, and I also, like, watched Marc's TV show. But he's a comedian, and he just interviews people. I think it started off with just interviewing comedians.

I think one of the episodes that really sold me on it was his interview with Tim Heidecker from the Tim and Eric comedy duo. And it the reason that one yeah. That that one resonated because, like, Tim is almost always in character. Like, no matter what he's doing, it's like, you can't tell, like, is he pacing serious? Is he not? But that specific episode on Marc Maron, like, I actually saw him as a real person. Like, he gave, like, a real a really good interview to, like, really, yeah, just, like, who is Tim and stuff like that. So, yeah, those are some of my favorites.

Yeah. Didn't you have, like, your Spotify rap was it your Spotify rap? Or, like, didn't like, you listened to an insane number of hours last Yarn. Disgusting.

Yeah. I think anytime you give away something for free, people are gonna take advantage of it. And I think, like, that's like, it kinda started I guess Wes was last year or end of end of year before that Wes Heroku removed their free free plan. And one of the biggest things they talked about was just spammers spinning up servers for, like, phishing schemes and stuff like that. And, yeah, if you if you offer things for free, people are definitely gonna take advantage of it. So I I think you're probably gonna see a shift into some more of the free tiers with sites like render and fly. Io. They they offer, like, a a base of, like, $5 free per month, but you still need a credit card to sign up. And you can, like, set alerts so that if you go over that specific amount of, limit, then they won't charge you or they will charge you. But, ultimately, they're just trying to make sure that, like, you're a real human with a credit card and not just trying to, like, use their services for free. Yeah. And I'm gonna plug a syntax Node, the host your own,

like a whole little like a home lab. Yeah. Like I bought like, I mean, I researched, like, actually putting servers in your house, but anyone considering doing this, do the research because you can watch YouTube videos of how loud they are. You do not want a server, like, sitting in your office because it'll just be spinning fans all the time.

And the question is, what is SemVer Anyways? Which is short for semantic version versioning. And, they, they had a really long story. I'm gonna summarize.

And, honestly, the story might even be good for, like, one of the the spooky Halloween episodes because it's about upgrading when they shouldn't have. But the TLDR is they wanted to use jQuery version 3 features, so they just upgraded without realizing that some downstream site was actually dependent on jQuery v two.

Clients got really mad. They started reaching out. Why is everything broke? And then they just downgraded back to to v 2. So I'll dive in really quick just to talk about what Simver is. If you wanna learn more, simver.org has a great explanation of of what this is, but you've probably seen it before. So if you're installing a package from NPM, it's always gonna have a three dot number. So that's the major number Scott the minor number dot the patch number. The current version of React is 18.2.0.

And so 18 is the major version, 2 is the minor version, and 0 is the patch number. And if a project is following semantic versioning, like the React library is, that major number, that 18, if that ever goes up, that means there are breaking changes. So that's why we see the jump from, like, 16 to 17 to 18. React has introduced backwards incompatible changes, and they're letting you know via the the version number the major version number.

The minor version number is for added functionality, so, like, new features that don't break things. So the next version here of React adds new features would be 18.3 instead of 18.2.

And then that last number is for patches and bug fixes. So if there's maybe not a new feature, but they fixed a bug, they would bump that to 18.2.1.

And there's other stuff to learn about this, like prerelease and, like, alpha and and different things like that. But when you see a version number like that, it's very likely that the project is using semantic versioning.

You should note, though, that any version number below version 1, there are no guarantees.

So you can expect breaking changes at any time. And I have experience with that more recently with Auth JS. So that's the project from the Next Auth team to make an auth library that will work with a lot of different back end libraries, not just Next JS. And it's still experimental, and they clearly label that on their website. Mhmm. So they are version 0.28.0.

So they're not even version 1 yet, but each each new feature, a lot of times, actually is a breaking change, and next time it'll be, like, 0.3 or 0.4.

So you can't always guarantee that they're they're following semantic versioning, but you should definitely, like, look at their the look at the library and and and see what they say in their docs. And then another interesting one is TypeScript. So TypeScript actually doesn't follow semantic versioning at all. Yeah. Yeah. Yeah. Yeah. And they they have a I'll ESLint in the show notes. There's an article that describes what exactly they do. I'll give you the short version here. So a new minor version is released every 3 months with new features, and then a new major version is released if the minor version would have exceeded nine. So if they if if they're going from 4.9 to if to 4.10, they actually just bump the whole version to 5. So they're they're actually you'll find that in TypeScript, a lot of times you can upgrade from 4 to 5, and there actually aren't breaking changes, and that's because they're not actually following semantic versioning.

Yeah. I mean, I completely agree. I I try to keep my workspace clean. That's probably the thing I'm worst about, but I always Node, like, I'm way less productive when I'm, like, tripping over stuff or, like, when things are super cluttered. So I always at least Node once once a week, I'll spend some time just like tidying up. I recommend calming decorations, you know, like, you can do greenery, plants, anything that, I mean, makes your your space feel more comfortable and relaxing.

I completely agree with lighting. So, like, if you have a window and you can do natural lighting, that's probably the best way to go because of our circadian rhythm and, like, actually seeing real sunlight when you're working during the day. But if you can't, you should look into lights that allow you to adjust the color temperature. So I actually have 2 lights here, and they can go all the way from, like, a really low, like, 2,000 k all the way up to, like, 65 100 k. And, daylight is, like, a a much higher k value. And so if you can find adjustable lights, that's that's another cool thing. Yeah. And then I would recommend if you can't paint or you can't do wallpaper, just use curtains. You there's actually, like, a little behind the scenes. There's no wall behind those yellow curtains there. No way.

They're just, and for the for the audio listeners, I have yellow curtains, like, way behind me behind all my stuff that I hung up. But I'm in, like, a big basement space, so I kind of, like, section things off with curtains, basically.

So, yeah, it's it's, it's super easy. It's not permanent.

And, if you want it to be permanent, you can, like, attach a curtain rod to the wall or to the ceiling or whatever else. But you can also look into photography backdrop stands. So, like, a lot of what people in, like, film and and TV do with, like, set design is they literally will just put up a stand and make it appear like there's a a window behind some curtains or something like that. And then I think to your point of, like, being a little bit embarrassed about the cloud background, honestly, I guess you could be a little bit vain about it and, like, kinda just focus on your back if especially if you're on camera camera a lot, focus on what people can see in your background. Because if for you, people if you feel like you're getting, I guess, better vibes or better impressions from people that are you're you're with on video chat a lot, that might also help with your own ideas of your of your workspace. So, yeah, like, try to make an interesting backdrop or at least a calm one. It's a lot better than just, like, a beige wall or, like, a stack of boxes or something like that.

And then I have a couple of notes because I think at the I read at the beginning of their question, they were kind of I I kind of interpreted it as, like, trying to find a workspace space at home. But mainly they're talking about, like, interior design. But I will say for anybody that is new to working from home, definitely have a dedicated space for that. So, like, when the when the pandemic hit and I was working from home more often, I did all my work from the couch. And that was not good. Like, I it it was very hard to, like, shut off my my work brain at 5 pm.

Also, I developed wrist issues because I was using the trackpad on the couch all the time. Yeah. So if you have the luxury of separate spaces, use them. So, like, I actually have a separate home office from my my, like, work office. So, like, end of the day here, I can walk, and then it's almost like a mental thing to, like, go into a different room and, like, now you're you're not working anymore and working on side projects and stuff like that. Or, like, if you're in the living room, it shouldn't feel like you're you're at work.

Yep. Next question comes from mister JavaScript.

And he says, hey, Scott and Wes. But, actually, hey, Scott and CJ. Do you ever stop to consider Vue. Js in 2024? Why or why not? Do you like movies with gladiators? On the gladiator point, I I guess I don't watch a lot of gladiator movies.

But, I I I've been use actually, been using Vue. Js for a very long time.

And I exclusively like, really before Svelte really took off, I would almost always choose Vue. Js for side projects.

And I also ran the Denver Vue. Js meetup here. So, yeah, I I have a a long love for Vue.

But these days, I I am reaching for Svelte more because I think one of the reasons that I liked Vue so much is that it Scott rid of a lot of the the boilerplate of React. It made it so easy to, like, build things without a bunch of boilerplate.

You can mutate state, which, actually, I'm a really big fan of instead of, like, having to work with mutable state. But, these days, like, I would say in 2024, if I were to choose you, it probably would be because of Nuxt, because Nuxt is also doing some really cool things, and that's the competitor or the compare you can compare it to, like, SvelteKit or Next. Js, but but for Vue.

But their dev experience is pretty awesome. I tried it about a year ago, like, right when version 3 was released, and it was still early days just because v three had just come out, but it's it's about the time I should I should try it again because it's the ecosystem has definitely matured a lot more. And then on the last point, Vue is also still doing cool things.

So Vue 3 Vapor was announced, like, a few months back, but I think it might have been released more recently.

It is basically like a compiler for for your Vue components. So there's definitely been a push in the web development world and front end to have, like, more performant front end Node, and vapor mode basically allows you to opt in so that you can get components that aren't actually using the virtual DOM, and have basically been optimized ahead of time. And so that's a cool thing they're doing that kind of gets them in line with the the cool stuff that, like, Svelte is doing or even, like, SolidJS.

I have. So most of what I know about it is it's what's powering Nuxt.

And I gave it a try when I was, like, looking at various, like, back end frameworks because, like, it it can kinda do similar stuff to, like, Node and stuff like that. Yeah.

I think that's all I got. Let's jump into sick picks. Cool. I have,

For me, I also am picking a food, and I have I have a visual Vercel guide. So Nice. I like I like spicy food, and I recently discovered pepper flakes from Flat Iron, Pepperco.

And, yeah. So the the thing about this is, like, I never thought that pepper flakes could, like, actually have flavor for me. It was also always, like, add some pepper flakes, make it a little more spicy. Yep. But this changed everything. Like so I especially like the the green, the Hatch, Hatch Valley Green pepper flakes. That's very Colorado of you. Hatch Valley. Yeah. Well, the it's it's Flat Iron pnpm Pepperco, so they're they're a Colorado company.

But you can find it, like, on Amazon. I think they're in a lot of, like, major grocery stores too. But, yeah, if you like spicy foods, it's super awesome. Especially, like, for me, I was using hot sauce on a lot of things, but it's fun to to switch it up every now and then use and use some pepper flakes instead.

Yeah. My wife got me the, the 3 the 3 pack for Christmas. So they have, like, a smoky one, like a traditional red, and then, like, a green one too. Yeah. Did she get it from the Savory Spice Shop? I don't know. Have you ever been to the Savory Spice Shop? I haven't. Okay. There JS a, a savory,

Nice. I'm just gonna pick the same. Is it okay if we shameless plug the same thing? It's it's more than okay. Great. Yeah. YouTube YouTube YouTube YouTube. Youtube.com/atsyntaxfm.

Subscribe, please.

And check out my videos because it's it's been fun making them.

And, yeah. Check out YouTube.

Peace.