Potluck

Welcome to syntax, the podcast with the tastiest web development treats Out there, we've got another potluck for you today. Some really good questions about how do you protect images on your website, and Should you learn TypeScript when you are first learning JavaScript or at what point should you learn TypeScript? We've got some really good ones on, rid. When how do you add ESLint, Prettier, all those things to an existing large project? We got some opinions on that. Some some pretty good questions. We are This is our 1st episode back from the, from the holiday break. So Scott and I are are back with a spring in our step, and we're stoked to be here. Rid. We are sponsored by 3 awesome companies. Prismic, which is a headless CMS.

Retool rid. Does, internal build tools are a new sponsor of ours. We'll talk about them partway through the episode. And LogRocket JavaScript session replay. We'll talk about all of them partway through the episode.

Happy New Year, Scott. How you doing? Man, I am doing good.

Feeling revived, feeling fresh, ready to go. Had a great holiday with the family.

Everybody, you know, just just, you know, there's some kind of amazing energy that comes from, like, little kids at Christmas. Yeah. And they're just so excited about everything. And, rid. We watched the Paw Patrol movie, like, maybe 25 times.

It's like, seriously, Wes, every single day, We we would give our kids a chance to watch, like, one thing as, like, a thing. Here's here's your your holiday.

You get to watch something of your choosing. Right? What do you wanna watch? And every single day, my daughter said, PAW Patrol movie.

And so a good one. We It is actually very good. Yeah. We're singing all the songs. We're getting all the The animation's got everything's good about it. Yeah.

We watched the, in Encanto, which is the new Disney movie.

Rid. And our kids probably watched it, like, 8 times over the holidays. And then last night, I came. I was doing some stuff in the basement, and I come up, rid at, like, 9 PM, and my wife's just sitting there on the couch with a glass of wine watching Encanto by herself.

Amazing.

I mean I was like, you watched Just 9 times or something. I love it. It's such a good movie.

We were sort of the same way with Luca. We saw Luca a few times. Oh, yeah. That was a good one. A good one. Which It's so funny because my my son really doesn't like, things that are, like, anticipation or or, like, really intense emotional kind of things. And so, like, he'd get really scared at various points of both Luca and the PAW Patrol movie, but then by By the the 2nd week of of watching these things, he was just, like, all about them. So nice little evolution.

Rid. Oh, that's great. Alright. Well, let's get into it. First question we have here is from Perry.

How do you protect Images on your website. Is there a native is the native platform more secure regarding this? So I I'm assuming he means, like, Is the native, like, a if you build, like, a Ios or Android app more secure, in securing images. And rid First of all, the answer to that second part is I don't think so. But because you can't necessarily just, like, right click view source or whatever on your things, It can be a little bit more secure, but not really. And I'll I'll tell you why. So I've thought about this a lot because, specifically Facebook, Instagram, a lot of these things, they have images that are only allowed to be seen by people who are rid. Friends with you or whatever you set your complicated, thing up to be. And with most things on Facebook and Instagram, if you Right click view source or right click copy image URL.

You're able to send that URL to literally anybody and they'll be able to do it. So I'm just going to break down real quickly how Facebook and Instagram do this, because they're probably the biggest example of this on the entire internet. So Facebook and Instagram have tokens in the URL, and those tokens are generated by the user. So it'll be, like, Forward slash images forward slash a b c 123, and then they'll have a whole long string of tokens in the query prem of that actual Image. And usually those tokens are associated with the person that is requesting, to view it. However, that does not Stop somebody from just taking that tokenized URL and sharing it out to the rest of the world because they will work. I've I've gone deep into this before because I've done Facebook scrapers and and marketplace scrapers. And I've, I embed Instagram into my own website via undocumented APIs.

Rid. So they just work. You don't have to be logged in to actually view them. So a lot of people say, like, isn't that, like, an invasion of privacy That anyone can just view them.

And the reality is is that somebody who does have access to it rid. Has to first get that URL, and it's no different than if they were just to save the image or to screenshot it if it was a native app and And send it on over. So, in my opinion, because the URLs are not findable, like, there's no way you could actually guess what a URL of an Instagram photo would be. It's not like photo 123.

Jpeg and you're oh I bet I could just type photo 124.

So that I don't think that's really not that insecure. You can go a little bit more, but if that was the case, you'd have to set up your own server Which intercepts every single request, sees if the user is logged in. And if they are, then you serve up the image.

And if that's the case, rid Then you have to send the the sort of the downside to that is you have to you have to serve the bandwidth of the image up On the same server that you're running the code to check the actual image.

There's other things around this on, rid. On CDNs. But generally, it's much easier just to,

allow anybody to to see the image if they have the URL because by the time you have the URL, You should have access to it. Yeah. A lot of interesting stuff there. It is funny because if you are trying to, like, save a photo from Instagram, you're normally just Copying and pasting the URL from the web portal into another thing or, like, an Instagram video. Like, let's say I have a a b boy video that I saw, and I wanted I wanted to save that.

I would I would I would find that account. I would copy and paste the web portal URL or look at the network request or whatever.

And, yeah, I wouldn't think of doing it from the native app. Right? Because it does feel like the native app is a little bit more secure. But you're right. I mean, there's there's kind of work arounds for everything. But it's I I personally think trying to protect any of that stuff unless you have like a major rid. Major interest in it is kind of a losing losing game.

People are gonna find workarounds.

Totally. Totally. It's it's probably a little different for files, rid. Then because with a file you can do that and you could just like redirect the user to the actual file. But somewhat different for files. But still again, rid. It's there's no I don't think there's a perfect solution unless you have lots of resources, like literally like server resources to throw at the Right. Totally. Not just developer time. Alright. Next question is from GMZI.

Hey, guys. I'd like to know How you guys learned TypeScript.

Did you use the documentation? What part of it? You read the whole thing or just What's needed for your project? Do you guys use an external tool? I'm using the handbook I found in the TypeScript docs, And, oh my gosh, I get so bored reading it. Any tips on would be very much appreciated.

Thanks, and stay awesome. Yeah. Okay. Let me agree with you so much here. I I found that, you know, the TypeScript docs are, like, great from perspective of if you know what you're looking for, you can kind of go find it. But if you don't know what you're looking for and you're just going to, like, get a better understanding of things, I didn't necessarily find them to be that great.

Me, personally, I learned TypeScript better by just heading to YouTube and just googling a bunch of YouTube videos for people to talk about TypeScript.

But that's also just more of a statement on how I learned better anyways is to hear people talk about things rather than to read them myself.

For me, though, the way I learned TypeScript the best is once I got, like, a handle on what it was, why I might want it, and some of the basics of the syntax and maybe some of the like, the differences between interfaces and types and those types of things would be to try to implement some basic stuff In my own projects, code that I was very familiar with, like things like React components, functions, then my code base, even then the server side stuff might have been a little bit easier for me because, Maybe it is a little bit easier to just do straight up singular functions rather than components and stuff.

But for me, it was really just getting my hands dirty and trying it out. And then that was, like, for the basics of TypeScript, was to just just try it. And you'll have a bunch of red underlines.

You're gonna Struggle through reading the messages, and then you'll get better at it. Get better at it. Get better at it. And then you'll feel very comfortable.

But I started to learn generics And maybe some of the more advanced, like, utility type stuff a little bit better by, me personally dealing with and reading advanced types that I found in things like GraphQL code generator, which would generate types for me, and then eventually having to write my own code generator plug in. So then I had to be the one writing those advanced types.

So it it definitely is a process of getting your hands dirty and really just trying, Trying. Trying.

But, you know, I I agree. The TypeScript docs for for some subset of people like me personally, they're gonna feel way too dry and Way too difficult to really gain a ton from if you don't know what you're looking for.

And like most things, I would recommend just writing TypeScript forcing yourself to do it. Struggle through the errors. You're gonna hit times where you're just, I don't understand why this isn't, You know, eventually validating. I've I've tried this. I've tried that. I don't get it. Just struggle through it, read the errors, and,

keep with it, and you will improve over time. Rid. Yeah. I I feel like this is a bit of my superpower in that, when I need to learn something new, I will I will literally read the entire doc. So I I did. I read through the entire TypeScript handbook, and I just try to suck it all up and not so that I, like, I'm, like, I read it and, like, okay. I'm I know it. I was, like, no. I just rid. I I read it so I understand the surface area of the tech.

And then I go on YouTube and watch a whole bunch of, rid conference talks on that thing. I put them on 2 x, skip the intro, skip the outro.

So then you again, you have a little bit more understanding of, like, why you might need it. Talked to a lot of rid. I was like, why do you use this thing? Why is this so good? And then once I sorta had, like, a good idea of the pieces, rid. What I did is I went to my JavaScript 30 course, and I converted every 30 every single one of those things over to TypeScript. I mean, that was great because some of them were just 3 or 4 lines. You just had to type out some inputs and, create a couple types rid For the data that we're saving, and it was done. And some of them were a little bit more involved. And it was a great exercise because I just touched upon a whole bunch of different projects. And, and I would say Or I would run into situations where there was 2 ways to do something. That's TypeScript is famous for that. There's literally 2 ways to do everything in TypeScript. Maybe even maybe even 200 ways to do some things. Yes. Yeah.

I would often add, like, one benefit of my, huge Twitter following is I'm able just to get some of the smartest people in the world on this stuff just to start talking about it. So I'll rid. Throw out a little bait y tweet on how would you do this in TypeScript? And you get a lot of really good opinions and thoughts and whatnot, which is it's just really cool.

And then I just start to use it in projects. So I start to build stuff in project. We talked about, my probably my biggest the or not biggest the first rid. One big project I did was the, t shirt seller, where I sold t shirts and did the shipping and printed the labels, all that good stuff. You can go back and listen to that podcast rid So does well selling t shirts with TypeScript, I believe it was.

So that's my approach.

But that's why I rid. Sell courses is that a lot of people don't want that sort of, like, everywhere here and there. Some people just wanna, like, sit their butt down And be mama birded the content and and and do it in a linear fashion and be told, alright. Try this exercise and then go and do it, and you can look at the answer. And a lot of people learn better that way and or at least the type of people that take my courses. So, this is a bit of a A softball to my upcoming TypeScript course, but that's exactly why I'm

Look at you. That's why exactly why I'm, I'm making that I think so. Get ready for that this year. Yeah. I had a little bit of that too where I did, like, a basic. Like, it wasn't a, like, an in-depth TypeScript. It was, like, TypeScript for beginners course, and it did focus forced me to, like, really focus on the the nitty gritties of when to use what and when to use like, what are the the core concepts that you need to understand here? And I think some of those those things can be, you know, very helpful. If you have, like, a a specific reason that you need to, like, dive into certain things, they can definitely force you to To really get into it. Alright. Next question we have here is from wasabi cowboy.

Noob alert. Scott, please please make your special sound effects. Scott?

Rid I did I don't know the software setup, so I'm very sorry I had to fake it.

Rid. So I've got the basics down, HTML, CSS, JS, and I'm working as a junior front end dev at a small company. Rid. Should I worry about learning TypeScript now, like, ASAP or stay focused on mastering JavaScript first? At what point should I rid. Worry about learning TypeScript. Is TypeScript better for some projects over others? I thought this was a super interesting question because, rid I so much so that I I put it out on Twitter. I'm like, like, what do you guys think, about this? Like, do should you learn like, on one hand, rid. If you learn types and TypeScript early on, you're learning a lot about, about rid. About how languages work. The autocomplete is awesome. The errors are awesome.

And then on the other hand, It's just another thing to learn and you're when you're frustrated with learning JavaScript, then there's this whole angle brackets everywhere and and whatnot.

Rid. At least what I my approach to this is that, yeah, you should definitely focus on JavaScript and, rid I don't know master JavaScript, but get 77% of the way there, because rid. That's going to show you. You're gonna start to once you get better at JavaScript, you're gonna start to feel the pains that TypeScript solves, And you're gonna understand much better. Like, a lot of times, I don't understand why a technology is so popular.

And then I hit the issue, and I go, oh, that's My people are so over the moon about this thing because I I now understand those pains. And, one of the rid We it was probably about a 5050 split on Twitter as to what people thought you should do. But, a couple tweets I'll just rattle off real quickly. I'll and then we'll let Scott.

Rid I'm curious what Scott thinks about this as well.

Rick Schennink on Twitter said, I feel that when you start out, energy is derived from getting things done Instead of doing it correctly.

After a while, you know you can get things done, and you get more energy from focusing on how you do it. Rid. I feel that that's the point TypeScript should be interested. Absolutely. I agree with that. Like, when I first started programming, I just wanted the dang thing to work. I didn't rid care if it was the best practice or whatever. It just needed to work and get done. As I got a bit better at JavaScript, I said, okay.

Now let's focus on, like, patterns and libraries and the better way to approach,

this type of thing. So I agree with that one. I think that's where I'm gonna side on it. Yeah. I think Rick nailed it. I, Rick nailed it better than any anything that I could have said. Because, you know, to be honest, I I agree. Like, you need energy when you're learning any of this stuff. You need positive energy. You need energy to stay with it. You need energy to push you through all the red underlines and all the broken code and exceptions and all that stuff. So You need progress, and it is tougher to make progress when you have issues coming from multiple sources or maybe you don't know if this is a typescript thing or a JavaScript thing. So I definitely agree. You you need to get you need to get some understanding of JavaScript first. You need to understand what problems TypeScript's even solving. I don't know if you yeah. Mastering JavaScript. No. I don't I don't think there's a handful of people who you could say master JavaScript because that's, like, such a big Big thing to even say. So don't necessarily even worry about that. Just worry about getting proficient, understanding what does what, where to go for what, and then Move in move in to TypeScript. Because, again, I like I said, I I don't think I would have even, like, understood why TypeScript is important, rid Without having some understanding of, like, the pains that it had caused me in various points of my life. So, yeah, I I think that's good advice. Rid. One more, thing. And this is something I did in my Advanced React courses. The Advanced React course, we

turned on TypeScript rid. For the back end of the thing because of how awesome the autocomplete was for the learners.

But I dialed back the almost everything in that, like, it would just work implicit any and all that stuff. You know, even if It's broken TypeScript. It will still run. And and why? Because at the very basic, you can just write JavaScript and get the rid. The really nice autocomplete in lots of cases because it's inferred. So maybe even do that. Like, just write your JavaScript. And rid. And v s code is even going that step further and, trying to find types for you when you're writing just dot j s files, but Maybe just turn on it as lax as possible in your next project and kinda get a a feeling for it.

Yeah. I agree with that. That could be nice. You know what else could be nice, Wes, is one of our sponsors, Prismic.

Woo. Yeah. Woo hoo. Yeah. Prismic is the headless CMS of your dreams, Wes. Do you wanna talk about it? Prismic is the it's a headless CMS. It means that you log in, you create your content types, and you relate them to each other.

They have a really cool approach rid to building websites, though. And, they've recently rolled up this thing called Slice Machine at Slice Machine dot dev.

And the whole, rid. The whole idea of it is don't ship pages, ship a page builder.

And and what that means is instead of saying, alright, here's the about page, Then the about page has a title and a bio and things like that. You can just you ship components.

You ship A details component, a person component, an image component, and then a a button component, a video component, anything you want.

And then you you have all these components.

They call them slices in Prismic, which you can you you can have your rid Your Nuxt JS or your Next JS or you can have whatever component you have, but then you have an associated set of inputs for that. And then you basically say rid to your end user, hey.

I made all these Lego blocks.

You can go ahead and build a page and literally use any of them that you want. Rid. You kind of just give them a page builder, and they can say, alright, cool. Give me a couple paragraphs.

Give me alright. Let's embed a video here. Oh, let's, Let's put 3 people here. We can put those in, and it's it's just awesome. It's just a really modern way to approach building websites. So Check it out. If you are building a website and you need a CMS for it, or even if you just wanna, like like, learn the sort of, like, rid. Awesome way of approaching your website. Go to prismic, prismic, dot I o forward slash syntax, rid.

And you check it out. They have a whole bunch of examples there as well. Thank you, Prismic, for sponsoring. Yes.

Cool. Well, let's, get into the next one. It's for Mohammed. Happy holidays. Happy holidays, Mohammed. I might be cheating a bit since there are a few related questions in this one. How do you decide what to learn? Do you prefer to be an expert in a few things or know a bit about everything? How do you guys handle FOMO? I have a big, the grass is greener on the other side syndrome. I always start learning something and then hear about another thing and shift that before doing enough in the previous thing. Sometimes I keep cycling back and forth or worse. Another contender for my attention appears, And I switched to that because it's better. After some time, I feel like I made a little progress on each of them because my attention was spread too thin. I feel like I'm the type that would rather know more about particular topics than a little about everything, but my grasses, greener syndrome keeps me from doing that. How do you guys commit Do what you want to learn and stick with it and be comfortable with the choice knowing that there's something much, something, much better out there. Okay. So this one's good for me. I'm, scatterbrained.

That's definitely one of the things I I like to move, from project to project. I like to do different different things. And you know what? I think I understand you.

I think I understand you a lot because there's there's always something new and better on whatever.

And people even joke, you know, I moved my my My library or my whole platform to sell kit. And then I did a course on Astro and a course on Remix, and people have Joked with me for both of them. Are you gonna rewrite it in remix? Are you gonna rewrite it in Astro? And I'm like, no.

You know? But the answer for me is, to commit to something is that I'm I'm most often never going to rewrite a platform in something else.

Most often, I say that as somebody who just did that, but you know that that platform was in React for a very long time.

And If I'm committing to a project, I'm committing to the project in the way that I started it, the way that I wrote it, and then I will use that project to expand. Now many times people really get stuck into things because it's just what they use at their job. Right? We use rails of my job. So therefore, I'm a Rails dev. We use React in my job, and then therefore, I use React for everything. And then in those regards, you kinda have to stick in that. And I think that's such a good thing to do is to be stuck in something like that because it it does force you to get deep into topics and to be good at those topics, And you have enough time to really explore that. But when you're just like a, you know, solo person learning, experimenting on projects, rid It it's harder. It's it's definitely harder to do that. It will take some self control and there is going to be self control involved here.

You do need to say, hey. Would I rather you kinda have to paint it in a picture of, like, would I rather advance This project that I'm working on, or would I rather keep the project exactly where it is and rewrite it from scratch? Usually, the answer is, like, I wanna advance this thing. I wanna make it better. I want to evolve it. I want to add new features and then grow it And whatever, more so than, like, I want to expand my knowledge. Right? I want this project to grow and evolve. I don't want this project to stay stagnant Because that's what happens. I I wrote I I took half a year last year or whatever to rewrite the platform in Svelte. And what happened, All of the features we were working on took a huge back seat in, you know, the features and the improvements to the site that we wanted to make As far as features went, they they didn't get to advance because we were focused on changing the platform to something else. So how do you learn, or how do you stick to that? Honestly, I think it is just a matter of working with self control or potentially forcing yourself to do it to say, like, rid Maybe I'll check out Remix or maybe I'll check out Astro, but I'm gonna do it for my next project, or I'm gonna do it for my personal blog or something. There's no there's no problem in doing that, but I wouldn't recommend necessarily hopping around too much in one project or another,

without without, rid. Like, really evaluating if that's honestly what you want to do. Yeah. I think us devs have, like, shiny object syndrome in that we ready. Something new comes out and you you hear a couple people hyping it up on Twitter and you think, oh, that's that's the next thing. Rid. You you want to move to that as as quick as possible. So, I don't think that you should really worry about rid. FOMO because if any of this tech is here to stay, you will know that. And in 6 months, a year, 2 years from now, it Will be dominant and or not necessarily dominant, but it will be well liked and well supported. And there'll be lots of blog posts and YouTube videos. And And, honestly, it's easier to get into something that is stable and well documented than this brand new thing, necessary. And I think also, like, finishing a project is a flex.

Being able to actually do that last 20% of a project And ship it out the door is going to push your skills so much further than jumping around from rid. One thing to another and and always talking about it. There's I see these people all the time where they're always just talking about Whatever is brand new. And to a point, that is Scott and I, because we're telling you what's new. We're excited about it. But rid. On the other side of the thing, you kinda just gotta pick something and stick with it. You don't wanna be that guy who's always just talking about the new stuff, but never rid doing anything with the stuff. You know? We get to talk about the new stuff because, I mean, that's literally our job is to explore the new things. Right? That's actually my job. Rid. Totally. So proof is in the pudding. Just finish your stuff, and then your next project, you can try something else out else new. But, I think rid The pain of switching and jumping on something that is brand new and shiny is often underestimated because of how rid. The APIs on those things change, and all that thrashing and API change and upgrades is is really frustrating after a while. So rid. Take it from me, a grizzled old developer who has done that many times.

Next question we have here is from rid. Allison.

I am a front end dev. I wanna become a full stack and learn a back end language. Which one should I rid.

Choose JavaScript.

Next question. No. I know. I honestly there's lots of good back end languages out there, rid. And I am obviously biased, but nothing beats being able to write the same language for your back end and your front end. And Scott and I are doing a show on Remix.

Nothing beats being able to write the same language in the same file for your front end and your back end.

Seriously.

Honestly, like, the as a front end dev, like, what happens on the server side rid Is starting to blur and I believe we will start to see a lot more of that.

We'll start to see a lot of, like, front end devs just becoming rid. Full stack devs because it doesn't matter where it's running. It's just just JavaScript at the end of the day. So I would double down on your JavaScript skills That you definitely have to learn. Go back to our fundamental server side fundamentals episode because you still have to understand what cookies are and what requests are and, rid routing. And you still have to understand all these major concepts. And Node. Js is the language to do that right now.

But it's You probably already know JavaScript, so that's that's a huge benefit.

Yeah.

Yeah. I don't have anything to add to it. I think that's fine. I we we at large will share the exact same opinions there. Yeah. Right? Whatever Latest and greatest thing is that I don't know that I'm gonna have to spend time learning. That's what I'll no. I'm just joking. Don't do that.

Okay. Next question is from Rich. Do Svelte components Not support media queries? When I try to implement them in individual components, they seem to be ignored.

Could that be an error on my part? There is nothing weird about media queries in Svelte.

So, Rich, you're doing something weird. Let's just say that.

But I I will say that there is some things that you do need to consider here.

Svelte components and their CSS are are really strongly scoped. So the CSS that you write is strongly scoped to that component unless, of course, you are using the global modifier.

Rid. It looks like a little, colon function that says global, and that could be potentially why you're Seeing some issues, maybe the code that you're trying to augment with that media query is not actually in that component. And because It's strongly scoped to that component. That's that's the issue.

You know what? I I really without seeing some code rich, I think that very well may be the issue, but if you're having issues with media queries in Svelte or SvelteKit, I'm gonna say it's most likely either because of the scoping Or it's because

you wrote your media query incorrectly. So 2 things, and I think that's probably it. Wow. I can't believe Rich Harris, the creator of Svelte, Put in a question about Svelte Tust.

Next question is from Tanner Wiltshire.

As a self taught junior dev, I often find myself intimidated by the task of implementing things like Auth or payment platforms, it's hard to know, what you don't know, and making mistakes with these types of thing obviously have serious consequences. Any advice or suggestions on how to approach things of this nature? Yeah. There's there's a couple things in web development that What you don't know can get you in trouble.

Accessibility is a big one, at least in Canada. If you are building a website and you make it inaccessible, rid you can be fined for that even if you you don't know. You kind of have to know those things. Right? And, the auth is a big one. You're trying to secure things in your application, and people can access it that can't access it. And that that's a big one as well.

What was the other one he mentioned here? Rid. Payment platforms. That's obviously a big one. That one is, a lot of the times Stripe rid. Makes that a lot easier because Stripe handles all the oopsie, parts for you, which is good so that you don't actually oopsie something important. Rid. But the answer to this is if you don't know what you are doing, then you can have these things audited, by you. So you can You can go to another developer that you trust and say, hey. Can you, like, run through this and ask me all the questions? Or you can find just some of these. You can There's everything from ScriptKitties who, are trying to get bug bounties on on websites and will just run a test suite against it, rid to see if there's any common, errors that will happen.

And then there's all the way to you can just hire companies and whatnot that say That will do a quick audit of your your application and make sure, that there's there's nothing weird going on there. There

The these are normal things to be intimidated by too, Tanner. So don't, like, feel weird about that because, auth, intimidating. Payments, intimidating.

Rid. Those are maybe even, like, 2 of the biggest, most intimidating things out there. So, yeah, in if if I were giving any advice on how to approach them, Approach them as if they are approachable, but also, like, take it step by step. Like, I did a course on authentication. And before I did that course Authentication, it did scare me. It was one of those things I was like, I can't do authentication. It's too hard. But then when you look into it, there are very explicit steps.

This does this, then this does this, then this does this, then this does this. And if you break it down into those individual steps, Take it 1 step at a time. You'll get the big picture and it will make it that much easier. And then you can try to implement it yourself.

But, honestly, the thing that helped me the most when approaching either of these things, which is things I've had to do myself, auth or payment platforms, is to take it step by step and even write out the comments, specifically the comments without touching any code. I'm going to first take the plain text password.

I'm going to send that to my server.

My server is then going to create a hash of that password. It's going to solve that hash. It's gonna do whatever. Right. The these are the individual steps, and you're gonna write them out in plain English to know exactly what it does before you even touch any code. And to me, that made it The process much nicer for me personally.

If you're diving into anything that, intimidates you, it's probably best to have Some sort of error and exception handling service. Maybe one, of course, that could give you a visual output of what you are seeing going wrong. And one of these platforms is LogRocket.

And now LogRocket allows you to see a session replay of errors and exceptions happening on your website With a video scrubbable replay as in, like, a literal video that you can see the click happen and then the error pop up, and you get the console. They get the network request. You can even get things like the Redux store if you're using Redux. It's a really, really, really cool platform and one of those ones that I personally use all the time, rid to help me solve errors because there's nothing worse than asking your client a whole bunch of information about their platform. Sometimes you still need to do that anyways, But this thing is just another tool that you can have in your investigator's tool belt to really get in there and solve some bugs.

And this is one that really helps you turn the lights on. Let me tell you. Nothing worse than solving bugs in the dark. So check out LogRocket at logrocket.com Forward slash syntax sign up, and you'll get 14 days for free. This is one of those services that you really gotta try. So check it out. Thanks so much for LogRocket for sponsoring.

Alright. Next episode is or next episode. Next question here is from Dan.

Dan says, Any experience working with a team on a different time zone? Any tips? So, Dan, I have a small team.

So take that as a caveat to this answer here. I have a small team, one of which our developers is a digital nomad. He works from literally anywhere. Sometimes I'll I'll message him, and I'll be like, yeah. I'm in this country. I'll be like, when did you move to this country? Yeah. Just thought I'd take a couple Couple of months in this country over here, and, it it's very funny because he he just bounces all around. And because of that, We've had to really develop systems for making sure we're all on the same page. So the biggest one is going to be communication and your Processes in your systems for communication.

Now obviously, this is going to change the more people you have involved here, but I think the rid I think the sentiment remains the same. Make sure that your processes are tight. Make sure that your issue tracking is tight. You have, everything assigned to people.

If there's an issue, somebody needs to be looking at something. They need to know that they are the person Who is now holding the ball? If you're tossing the hot potato to somebody, they gotta know they're holding the potato, or else it's gonna blow up in everybody's faces. Right? We just played hot potato with my kids. In case you can't tell, that that is well, that's where the hot potato thing comes from. But okay. So explicit issue cues, Task management, those types of things. We use a to do system called height, but you could do this in GitHub issues. If somebody is assigned to be working on something, You take yourself off of it. You move it to them. You update the notes. You commit frequently. You make your commit messages very clear.

You state explicitly what branches they're on or you have a system for the branches. Sometimes, we don't do this anymore, but we used to have our branches be the GitHub issue, The number at least since change it a little bit, but that could be something that's very helpful. Either way, the biggest most important thing is that you You always have up to date code if if you expect somebody to be doing something. You always have up to date code in the remote, location, whether that is GitHub or whatever. You always have up to date code there. You always have everyone's task listed as who's doing what. Everyone should always know what the status of things are, and that's really it. Take an additional hour at the end of each day To flush out your communications, commit, push up, assign things, tweak things, add priorities, add those types of things, and everybody will be on the same page. That way, it doesn't matter when someone's picking up. They can just open up their computer, see what things are assigned to them, what things are in high priority, what they have to work on, and pick up from there. Again, the bigger the team, maybe the harder that's going to be. I'm not talking like Google sized organizations here. But if you have 10 people on your team, 20 people, These kind of things should definitely work. Also, communication channels like Slack and Discord, they get a little bit harder when people aren't on the same time zone because you can't just ping somebody. So, again, having a singular place that's like the the GitHub issue queue or your, your what do they what do they call those things? Are they like, if you have, like, a A task system.

We use Height app. It's basically just a fancy to do system. But, like, if you have those systems up to date Issue tracker. Issue tracker, whatever.

That is really the biggest thing to make sure you're organized there. Yeah. I I've been working with a guy out of South Africa for a while, and, it's rid. 7 hour difference. So if you're working a regular 9 to 5, there's a 1 hour, really, overlap. And, rid. Also, I talked to the folks from Keystone. They're in Australia, which is, very, very hard to to Get any overlap with people in Australia.

Denise, people you had some of those bluey episodes?

Yeah. Oh, yeah. That I don't We had a lot of people talk to me about the the Bluey episodes.

Rid. So for me, the hardest time is just remembering what time it is in the other time zone. I when I was a contractor, I worked with a lot of people from the UK, Lot of people on the East Coast, and I I've started using this app called Clocker.

Rid. I've only just got it today because that's exactly it's funny that this question is here because this exact issue I have is it's a little as much as I hate menu bar apps, I I just want to be able to click on a button and see what time it is in whatever other time zone. So my assistant lives in Saskatchewan.

Rid. And Saskatchewan does not have daylight daylight savings.

So if half the year, they're 2 hours behind, rid Other half of the year, they're 1 hour behind, which is annoying because it changes because we do have daylight savings.

So this rid You just click it down, and it will tell you what time it is in in their time zone. I use I stat menus for that, by the way. Oh, wait. I stat menus does that? Yeah. You can set a bunch of you can have as many as you want, and then it'll have all the clocks.

Oh, what am I doing an extra app for that? Ice set menu is the best. Yeah. I said menu is great. Yeah. Oh, you should have sick picked that like a year ago, Scott. That's awesome. Yeah. Sorry about that.

Rid My bad. I'm gonna I'm gonna have to set that up after this call. I'm gonna get rid of Clocker. So there's that, and then just being aware of people's time, try to do things. Rid. A lot of it has to be done asynchronously.

So the first thing I do in the morning is try to answer as many questions as I get asked, and make sure people aren't blocked on specific things.

And then, that's really the best I have.

It's rid. The other thing is that sometimes people have to be flexible. Sometimes you gotta jump on the computer at 9 PM or sometimes you it's it's really Tricky for me to do early because you have to bring the kids to school and things like that.

But that's that's sort of the best that I've got, The best tips that I have, unfortunately, don't have to do it too too much with people outside my time zone. Yeah. Same likewise.

And I I think that is important to know the time zones and everything like that. And then even finding ways that, like, one thing that I like to do is rely on Tools like like video screen recording and stuff, and if if you're on a Mac, you can quickly record a screen recording.

Sometimes that is like like one of our. This is this is not a paid ad read here, but one of our sponsors, LogRocket, does the session replay. Right? And that really helps you to solve bugs. But in the same regard, you can take that video approach to solving bugs and issues by just straight up screen recording your local environment to say, By the way, this is what I'm saying.

Can you help with this? When I do this Yeah. This happens. That can sometimes be much better Then trying to explain it because a straight up video of somebody doing something is usually a better indicator of what happened than than like a text 1 line by line, here's what I did. Click, click, click. The video sometimes can help there. I we utilize those tools to say, hey. This is what I'm seeing. This is what's going on. Can you take a look? Oh, actually, along the same lines, Wes, about the, the clocks. You know, the ISTAT menus has the the clocks and whatever. And my My one of my 1st dev jobs, we had an, employees that were living in LA in Germany.

And, oh, man. They they had, like, Like, you would see in, like, a newsroom. They had, like, analog clocks set up on the back wall that were, like, LA, Germany, Ann Arbor, it had, like, all 3 of them, so you could just, like, turn around and look at the wall to see what time it was. Like, real analog Clocks of all the different time zones. I thought that was really cute. It was, like, a nice little way to do it that wasn't, like it was it was them all mine. Intentionally aesthetic and rather than utility,

you know. I'm just looking at the I stat menu time. Somehow, I didn't know that this is on there. So you just add locations. Can you, like, name the locations, like, after people? I don't know about that. I for me, I always had, like, rid. The I just had them in there, like Tokyo and whatever. Whatever city they're in. Yeah. Yeah. Makes sense. There's I don't know if that's really that much of a mental barrier to say, alright. They're in this city.

Who do I know that's in Saskatchewan?

Rid. Yeah. It's true. Like, for me, it's not a big deal. When I when I did, consulting, some like, the project manager, they've got rid. Thirty people they're meeting with. And, you know, like, they have to constantly be thinking, who when's rid Like, when's an okay time to schedule a meeting in your time, you know? Like, oof. Calendly is so nice too, though. You know? Yeah. You just tell them to book something with you in your open spot. That's maybe a better approach.

Alright. Next one we have here is a question from rid Adel from beautiful Norway. I really like this question, because I just designed similar myself. Thanks for the great Podcast. I often listen to it when I'm out running, inspiring. And I learn a lot and hear about services I should check out but never get to.

Beautiful.

I'm a consultant working on a React project with 5 devs and rid Three more who have been on the project previously. When I got in, there was no GUI library and, ESLint rules cause a 1,000 plus warnings on each build.

We got rid of them, introduced Material Material UI. Now we have mixed style components, blah blah blah blah blah.

Rid. As you may imagine, as I won't read the whole the whole question because people get bored of that. I'll just get to the point here. As you may imagine, at least many Different code styles and developers from almost 60,000 lines of code. I would like to introduce Prettier to avoid all the discussions on code style, Syntax, etcetera, etcetera.

But the the problem is is that, Prettier correction would ruin the entire git history, Which sometimes is useful for who made the code, how old it is, what feature or bug it was last changed. Perhaps a git history would make those previous comments available, at least partly. So rid This is is really interesting. I just did something similar on, I'm working on a big update to my course player, and we had something like, rid I think it was, like, 60,000 between ESLint and Prettier.

Just tiny little things. Like, I had changed a bunch of rules, and I hadn't run it rid In in a long, long time, and it was insane how many it was. And you have kind of 2 options, when you are, like, alright, this is a big, big project.

You can go nuclear where you just run it all at once. You make 1 commit, rid. And you fix everything that can be fixed in one go, or you can do it as a add on an as needed basis where rid Okay. Okay. I'm working on this file right now. Let's use the Versus Code plug in to save it. And when it saves, it will reformat it. And then you sort of just go through the code base rid as you touch different files. And whenever you're working on something, you change it. So, I initially thought I'm going to do it on an as needed basis, just because it seems so overwhelming to rid to do all that type of thing.

And I quickly learned that that's a pain in the ass because when you want to work on rid A new feature you don't want to have to fuss with. Prettier's Prettier's not a big deal. Prettier just fixes it. But for ESLint rules, little things here and there, You have to actually refactor it. So, what I did, I just I just hunkered down 2 hours. And, like, it sounds silly. There was 60,000 Errors are 40 I think it's 40,000, something like that. But they were like like 38,000 of them were just like little spacing indentation, rid. Quotes, extra lines, imports that were unused, things like that. And then those all just got cleaned up very quickly. Rid. And then I just went through each file 1 by 1. It took about 2 or 3 yeah, about 2 hours to go through it all and get it to 0, rid. Which felt pretty good. I always love those types of projects where you you you fix something And then you you either run the thing or run the test, and then you have less. And every single time you run it, you have less and less and less, and you just try to get it down to to absolutely 0.

Rid. I asked this on Twitter as well. Like, what do you do? I'd much prefer to go nuclear.

A couple of people mentioned that Couple of people mentioned that git has a ignore revisions flag when doing a git history. Rid. And you can put this in your git config or just use it as a flag when you run it, and it will specifically ignore rid those revisions and show you the commit before that. So, pretty sweet. That's I think that's the answer to that right now, and And I would probably do it all at once. And another, really good point that someone had in this is how I did it as well is you do all the Fixable ones that don't actually break your code. Prettier is not going to break your code. I've at least I've never run into a situation where Prettier rid Broke the functionality of the code. It's pretty good about that. But ESLint rules can break your code.

Things like, Reassigning an argument. You know you have an argument coming into a function, and then you like one example is I have a function that takes in an email address, And then I want that email address to be lowercased.

The ESLint wants you to make a new variable called lowercase email and then Take the argument and lowercase it. And what I was doing is I was just overriding the argument that was being passed in. ESLint didn't like that. So I just had to refactor the code a little bit. And there's a possibility that you introduce bugs into your software at that point. So, I would do those in separate commits and then Make sure they work. Have tests for those things.

That's sort of the way to approach that.

So anything that Requires actual review should maybe be in a separate commit, maybe even a separate pull request.

Yep. And, like, if all of that sounds too intense, I do think One of the things you mentioned there that, just turn it on in Versus code and only update the file as you go is definitely an option too. We did that, Recently even with TypeScript, it was like I mean, that's totally different because that that can definitely, change some things in your code base at all, but, rid. We had that issue where it was just like, you know what? We're whenever you work in a file, that file should end with no TypeScript errors, but it very well may start with TypeScript errors. So that that worked well for us, and, it it took it wasn't like it wasn't like a a a short process. It took Of course of time because there's just some files you never touch, and then sometimes files open up a can of worms and all sorts of things. But it did it did, like, work well, I think, for us. Cool. I I thought thought that was a really interesting question. So thanks for submitting that one. Totally.

Next question here is from Alex. Alex says, what are your thoughts on mono repos? Keeping all of your company's code in 1 managed repository versus separate repositories for different code bases of the show, peace out. Okay. So It's funny. If you listen to some of our older episodes, people asked about monorepos. And I think, I personally have the wrong idea about monorepos in the past, But I use a mono repo right now. We have several packages in the mono repo. We have our API. We have our UI. We even have our old admin UI. Everything's in the mono repo.

We use PNPM workspaces, to organize all of that, and I really, really, really like it. I think it's great. I think it's fantastic.

And the hardest part for us was, like, we wanted to have some packages private and some packages public, of which we ended up using submodules even though some people Not liking some modules. They ended up working out just fine for us. But, I gotta say, having a monorepo has been very, very good for us Because one thing that we can do is we can write small little packages of shared code between the different packages.

You can just reference those as if they are real packages Even if you're not publishing them somewhere, for instance, I know workspaces like this in Yarn or NPM kind of work similar, We can just do at level up tuds forward slash shared and then access any of our shared utility functions. That way, we don't have to write All of our date utility functions more than once. We don't have to write any of our string utility functions more than once. You know, it's all this stuff. It's like They exist in one spot, and we don't have to worry about code duplication or bugs being introduced by having it, not being available. So What do we think? I I really like monorepos, especially for, like, a project of my size level of tutorials. I think that works out very well. It's funny that this question comes up again. Just this morning, we're working on,

moving over My boss monster is the name of the That's a good name.

Yeah.

The boss monster is the name of the The course do you know what mine's called, by the way? Platform. No. What is it? King Tut.

King that's amazing.

Yeah.

Rid King oh, I like that.

So mine is being moved over to a, a monorepo, and it's going to be less of a boss monster rid might be more of a boss mono, and we opt to opted to try out, turbo Repo, have you heard heard of this? Oh, I'm excite

I'm very excited to hear your thoughts on this because I talked to Jared about that a long time ago before it was, like, available.

And, Yeah. I'm interested. I'm I am interested because it's supposed to be turbo turbo time. It's supposed to be very fast. So it's like

a build system for mono repos. So if you've got 15 packages in your mono repo and you need a build system for that, that's what it does. So rid Vercel bought them.

It's supposed to be super fast. There's another one called nx@nx.dev.

Apparently that one is wicked fast as well.

I'd probably like to check out that one as well, to see.

I don't I don't know if the speed is necessarily gonna be an issue for me, but,

rid. It'd be kinda interesting to to take a look at both of these. The biggest pain points for me, Wes, would be, like, setup. And each time you have to set up a new package, you gotta think about Build steps, build process, and some of that stuff's fine if you're using, like Yeah. SvelteKit or whatever. I don't want I don't want to have to have a unified build system, But there are times when I'm like, oh, I just want to write this in TypeScript, and I want it to be consumed. But I now I have to set up a build to convert it to JavaScript and all this stuff. It was kind of a pain in the butt there. Rid. Oh, yeah. Interesting.

So, that was just, like, like, an hour ago. So and, don't know don't have any opinions on that just yet. So maybe we'll do a a show in a month or 2 on, monorepos and these these popular build tools in that regard. Book it. Rid. Book it. This episode is sponsored by a new sponsor today

that is retool.com.

That is ret0ol.

Now not only is this one of those sites you're gonna wanna go to for some homepage inspiration because it's really nice looking, but it's also an amazing think tool for building internal tools. That's right. If you're building tools like Wes and I, honestly, we talk about love building internal tools.

But a lot of times you need the internal tools to just work, and you don't wanna spend the time having to hack together a forum library or anything like that or hack together a charting library. What Retool allows you to do is to start shipping today because they have their own