Potluck - Beating Procrastination × Rollup vs Webpack × Leadership × Code Planning × Styled Components × More!

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready.

Tolinski

and Wes Bos. Welcome to Syntax. This is the podcast with the tastiest web development treats out there. Today, we got a potluck for you. Potluck is an episode where you submit the questions. Scott and I will bring the answers. If you have a question you'd like to bring to the potluck, please submit it. Go to syntax.fm.

There's a button in top right hand corner. You can submit any question or show suggestion or anything that you want in there, and that that helps us out. And I love doing these episodes.

Today, we are sponsored by 2 awesome companies. First 1 is LogRocket, which is all of your logging and session replay for your JavaScript And the next 1 is Sentry, which does your error and exception tracking for all of your applications, front end and back end. We'll talk about them partway through the episode. With me, as always, is mister Scott Talinski. How are you doing today, Scott? Hey there. Hey there. Hey there. Doing good. It's funny. I just listened to the episode where I was talking about jailbreaking my

phone. I un jailbroke my phone last night. So Oh, how come? There Wes just a Apple developer conference, and, I really wanted those widgets. I gotta have those widgets, man. I I gotta have them. Bos 14? Bos 14. Yeah. I'm installing the developer's preview, baby.

Looks really cool. I'm excited to finally have which. It's so funny. Like, all of the stuff they announced Wes, like, Android had that for, like, all of Yarn? All of all of the features. The the global search and the iPad.

Like, just about all the features were but I I'm so here for it. I'm very happy to have them. And in fact, I just found, was it inputs.com? Is that the site? Inputmag.com.

They just did a thing. I've never seen this site, by the way. This is a really beautiful site if you if you've never seen inputmag.com.

This is a really good iteration of, brutalist design. Variable width fonts here. Yeah. They do a lot of cool stuff. They they revealed that there was a, a really interesting new feature buried in the accessibility settings to do, like you could, assign the different tap sequences to do different things. So you could do, like, tap, tap, swipe, or something to initiate a Google Assistant query or something. There's, like, a whole bunch of interesting things about it, but they're under accessibility and nobody else was talking about them yet. So, oh, I Wes, I'm gonna that. Oh, I guess, I'm gonna that. Cool. Yeah.

Awesome. Well, let's jump into the potluck now. You wanna grab the first question? Yes. 1st question is from anonymous. Hi there. Love the show.

I can honestly say the show has helped me become a better and more knowledgeable developer, so thank you. Thank you. You're welcome. I am a junior dev coming up on 2 years at my current agency.

I have been primarily on the front end using Angular and templating with handlebars and HTML and CSS.

I even asked if I would be interested in moving more onto the back end to focus on Node. Js. I would love to become a full stack, so I'm all for it. So I'm wondering outside of creating APIs, what else should I learn to do in back end? Wes, I think you got this 1, mister, Node. Js.

Yeah.

Mister backend, they call me. Bet they they do call you that, I think. Mister backend. I'm gonna start. That's a good nickname to add to the list. That's a joke that I have with my wife JS anytime there's, like, something funny, I say that's that was my nickname in high school. Oh my gosh.

Anytime anytime there's something hilarious, I say that. It's it's a it's a sure laugh from my wife. Anyways, calm down. Good laugh. That's a good laugh. Yeah. That's what they called me in high school. Try that try that on your significant other and see see what they think. So question is, like, I wanna become full stack, but, like, other than creating APIs, what else should I learn on back end? So, like, creating APIs is certainly a large portion of it. And under under all of that, creating an API, I think there's a lot more you can learn like authentication, doing JWT, OAuth, all of that. That's a whole can of worms right there. And database calls and data aggregation is another big one. So if you wanna be able to like, even in my Node. Js course, it it was half complicated to, to get the average review of all of the reviews of a specific store. Like, that's that's not trivial because if you have a 100,000 reviews on a store, you can't just query them all and then for loop over over them and add them up. You have to do that as an aggregation on your database so it's nice and fast.

Server side templating is something to learn. So I know a lot of people think that, like, server side templating is dead, but we've got a a hasty treat coming up. Or maybe it was the per the last Node, depending on the order that we're recording this. Just about, like, server side rendering is back, and it's it's more popular than ever. And and there's some really cool apps that have been built lately that are fast as heck. Email templating, that's a whole whole thing. Sending email, sending transactional email is is very important. I say almost every application has some sort of sending email.

Cron Bos sending stuff every x hours doing something when something happens, webhooks, that's another one. Oh, yeah. There's a huge list I just just rattled off that came off the top of my head. And I think that all of those are things that you could you could practice and get better at being a back Yeah. The only thing I would add on to here, because I think you did a great job with this list, Yeah. The only thing I would add on to here, because I think you did a great job with this list, Wes, just thinking about, like,

security and Scott, like, not, like, securing your server, but, like, when a query comes in on the client side, we know not to trust anything. Right? We know not to trust anything coming from the client. Right? We should never just blindly trust that information coming from the client. So learning how to properly identify that the person who is intending to do the operation has the access and ability to do that operation.

Because, again, that that's sort of your last line of defense before either inserting things into the database or running code on the server. So that's the only thing I would add to it.

Awesome. Next question we have here is from Cletus Diaz. Hi, guys. I love the podcast. I work as a webmaster and would like to be a front end developer someday. That that's a good question. Like, what's a webmaster? Scott, what do you think what do you think a webmaster is? Currently,

somebody who potentially is just, like, watching over a site for a business. Like, we have a business. We have a company. Here's our site. I'm the one who make sure the site stays online. I'm the one who make sure the site is updated or whatever when it needs to be. Maybe you're not working on multiple projects. It's like you have a project that you're just managing. Is that is that that's what it comes to mind for me. I would think that too. Like like content, new pages, contact forms Managing a CMS.

Things like that. Like, maybe not necessarily building the thing from scratch, but,

yeah, kind of just hurting it throughout the day. Even if it's like a just like a straight up code based system, like HTML pages. Right? Oh, we need to add a new page. Right? You gotta go and you gotta copy a new HTML page. You gotta change in the Node, those kind of things. Yeah. I think that's probably a lot more common than we we think.

So that's kinda interesting. Next is question. I currently, I'm working on a MERN Stack app. So MERN JS, MongoDB, Express, React, and what's the end Node? Node, obviously.

There you go. Stack app in order to enhance my own skills, but I have problem focusing, and I tend to to procrastinate a lot. How do you tackle distractions to get things done? I would appreciate some tips. So Oh, man. At least for me, in my life, if I'm procrastinating on on something like that, it's usually because I'm anxious that I don't know how how to do something, how to tackle something. If I look at anything in my life, whether it's just like projects that I haven't finished or whatever, it's because I haven't I'm a little bit anxious, so I don't entirely know what to do as my next step. And for me, the way Scott of around that is to break things up into smaller tasks.

And by breaking it up into smaller tasks, it's a little bit easier to

sort of take a bite of it and research what you need to do to to get that one thing done. So that's what I would say to do there. Yeah. I would agree. I I so one of the things that I like to do is to find the source of your distractions and then just absolutely remove them. I don't know if I have the self control to really, like okay. I got I got a computer screen. I got a big old monitor. I got a phone, you know, all these gadgets and gazmos and widgets and, you know, all these things. Right? I I I just I just wanna look at it. Right? I gotta I gotta check Twitter on the 8th device today.

So, for me, it's really important to assist myself in ways that I'm unable to do it myself by, with the use of software. I use an app literally called Focus for Mac. There's a bunch of apps and tools. I don't know exactly which on what, all the different platforms at this point. But what you're normally looking for is something that blocks certain sites for you. And oftentimes, like, yes, there are ways around a lot of these applications.

But if I pop open a tab that like, I start typing TW and then I hit enter and then it takes me to Twitter and then it greets me with a, like, a quote message saying, you should be doing work. And then I oh, god. Oh, okay. And it what it does is it makes me acutely aware of just how compulsive checking Twitter can be for me or checking Reddit or even going to certain forums or or different things. It it reveals to me more than anything just how compulsive the behavior is and then Node Totally. Yeah. I'm doing it compulsively because I, like you said, I I'm I'm trying to be distracted. I'm not trying to focus.

So once you put all those blockers in, I highly recommend that app, Focus for Mac. I don't know what the other app. People always ask me about different apps, but there's a ton of apps in this in this category that you could probably look into and install.

You know, I I think that's the way to go for me. If you can't do it yourself, if you have a hard time focusing, let the robots help you focus for you because, you know, that that will help a lot. Also, it really helps to put yourself in a position where you're capable of focusing. You know? It I know it's it's, not necessarily great advice right now considering the current, you know, global pandemic and stuff like that. But for me, always going to a coffee shop or someplace like that was always, like, a a really good solution for when I had trouble really getting in in the zone because you just feel bad if you're at a coffee shop and you're you're browsing the Internet or something. So, like, use all these tools. Granted, coffee shop Node a great one right now. Maybe you can go to a park or something and tether your phone or I don't know. Either way, put yourself in a position to focus, get your everything in order, put your focusing apps on, and then just go to town. Good. I like it. Yeah.

Next question here is from Jonathan. Jonathan, this is gonna be a fun question. Rollup or Webpack? Webpack 5 still doesn't have Wes 6 module output. Oh, it doesn't.

As described by Philip Walton here, here's an article he links to a blog post. So instead of upgrading to webpack 5, this might be a good time to think about switching to roll up our parcel.

So my thoughts here is that at the end of the day, use the tool that you're most effective with. But let me tell you, I have not modified a webpack config in a very long time. I think the only times that I've I've used webpack recently are with a Gatsby site or a Next Wes site. Everything else, my own personal site JS on the Meteor. My side project's also in Meteor, so I use Meteor's build tool, which replaces all of that stuff. In terms of using Parcel or Rollup, I have been using Rollup for a lot of stuff lately, Scott because of any specific features, but mostly because Rollup is, in fact, you know, the main build tool in Scott of the Svelte community.

And that's largely because Rich Harris, who created Svelte, seems like he created Rollup as Wes. And so you'll see Rollup being used quite a bit. I also have been using I forget what it is. I've been using some sort of a package library to create other packages, and that uses roll up as well. Oh, t s d x. TSDX by Jared Palmer JS this TypeScript Deno config.

It's like a a starter for creating packages. Specifically, I use it for creating React packages that uses Rollup as well. So I'm just I'm just very used to, Rollup at this point. I don't I don't know what it is. I haven't seen a a webpack in a little while. Yeah. Me neither. It's been well over a year since I wrote my own webpack. I always reach for Parcel. It's so easy to get up and running. Parcel 2 has been cooking for a while now, and I bet it'll be out in the next 6 months or so. Yeah. I just saw beta. Oh, did you? Oh, awesome. That's that's really good. I I love the the ease of use in Parcel.

Just up and running, you can kinda just it has, like, a dev server built in as well and handles all of your images. It's it's pretty, pretty nifty.

I use it in couple of my courses. It's kinda interesting you say, like, that Webpack doesn't support Wes module output. That's kind of cool because, like, I never thought about that. Like, I'm not shipping ESX modules to any browser. Yeah. I'm still always kicking it out to just regular JavaScript bundles and whatnot. But yeah, not to say like throw any shade on Webpack. Webpack is super Yeah. Capable. It's just that everything that uses Webpack for me, like, I think Gatsby, I think Next, they're just under the hood, and people much smarter than I are able to tune that thing for me. And then I just use the the simple tool on top of it. Yeah. Exactly.

Next question we have here is from Kiko. I have been learning web development, HTML, CSS, and JavaScript, and I'm at a place where I can build simple websites for small businesses. But I feel like a beginner, and I'm wondering if you have any recommendations on courses to get a more immediate, intermediate, or advanced level.

Yeah. I I I obviously, as someone who sells courses, I'm I'm here to tell you you can go grab my beginner JavaScript course that will bring you up to intermediate level.

Any of the courses I have, any of the courses Scott have as well. But at a certain point, you Scott stop looking for that golden blog post or course or YouTube video or person to follow on Instagram, and you just need to to keep grinding. The the way you get from beginner to intermediate to advanced is not by a course. It's by literally just putting in the work and building stuff. So just start building a 100,000 projects. And over the course of building those things, you will become intermediate and advanced.

Yeah. Get those reps in. Another tip I might have is to, find, like, find things that are interesting to you. I'm I'm not talking about, like, hobbies or side product. I'm talking about, like, things in code. Find aspects of code that are very interesting to you, I e, if you wanna take a little short detour to look at, like, my Canvas stuff. Maybe you're interested in Canvas, or maybe you're interested in web animations, or maybe you're interested in, something really mundane like, Regex. Right? But take that detour time to really deep dive into something and and just let your curiosity drive you. Because oftentimes, when we're really motivated to really dive into something, we learn a lot better. So if you're feeling like this beginner and you wanna get more intermediate, find a topic that it seems interesting on the surface and one you could just dive into. Maybe you wanna learn how webcam works or something like that. You what what is the web app? For some reason, I'm blanking on the web technology. I can only think of, like, Wes WebRTC.

User medium? Yeah. Gate user media. Exactly what I was thinking of. Cool. Yeah. So what I was thinking of. Cool. Yeah. So just let your your curiosity pull you in different directions, and that's going to lead you to create different projects. And, those different projects will lead you to learn more things. Like you said, get those reps in.

Oh my god. This is the funniest thing ever. Whenever Wes wants to do a transition, he always types in all caps in the Notion thing, and it's he he just wrote, speaking of projects, how about replaying your session? I don't know if that sounded better in your head, Wes. It doesn't sound great out loud. Oh, how how am I so bad at transitions to ads when you are so good? I don't know.

So okay. We were talking about, like, that your your, you know, your curiosity drive you, and you may hit some snags along the way. But when you hit those snags, you're gonna have a tool like LogRocket to replay those sessions for you and allow you to see what exactly is happening when your users are on your side. I don't I don't know if that would necessarily works, but it could work. Let's talk about LogRocket here. LogRocket is the service that allows you to see what happens when something goes wrong on your site. Let me tell you. It plays nicely with another one of our sponsors that we're gonna be talking about later on in this episode. In this really, really cool service, what it does is, basically, you just drop, I think it's just a a simple JavaScript file in your site, and all of a sudden, you connect with the config.

You get this really neat session replay. It's this video log of what happened when somebody clicked something or did something and your site broke. Their headline is Scott guessing why bugs happen, and that's really the best way to describe this service because it's no longer looking at error logs. Granted they do give you error logs. It's no longer just looking at these big, you know, exceptions.

What you're actually watching is a video of the the crime happened in action so you can go and solve it like the good little, detective that you are.

Yes. It is a it is a crime oftentimes when the user somehow managed to click on the only thing that they weren't supposed to click on and it broke everything, because that's just how users are. Right? So what you're gonna wanna do is head to logrocket.comforward/syntax, and you're going to get 14 days for free. So give it a try and check out log [email protected]/syntax.

Thank you so much to LogRocket for sponsoring.

Alright. Next question is from Jonathan.

Why would you choose a style component over other ways of writing CSS? Okay. I'm working on a CSS course right Node. So I've my my brain's definitely in the CSS territory. Right? I'm thinking a lot about CSS and what things are most efficient and whatever. And I use CSS custom properties or also known as CSS variables for just about everything nowadays. I'm I'm just very into them. Right? They do so much for me. And I began thinking like, alright.

What is style components giving me here that I cannot get with CSS variables? What what is like, what's the difference between having it and that? And I've become acutely aware of this because I have a project started that's on Meteor and Svelte and a level of tutorials, which is on Meteor and React. And, obviously, Svelte doesn't have styled components. Granted, you can do CSS and JS, but I thought this would be a nice opportunity to see just how much I didn't need styled components or just how much I needed it.

And I ran into a couple of use cases where I found style components to really help me along. For those of you who don't know, style components is basically creating a, like, almost like a custom element that is just CSS, really. Right? Instead of having a div, you would have a card element, and that card element would have CSS applied to it. And instead of there being a class of card on a DIV, you just have a card. Right? The cool thing about styled components, though, is that because they're a component, you can pass data into it, and it makes it so that you can have that CSS work dynamically based on JavaScript in a much easier way than having to write all that JavaScript by hand yourself. It's almost like you're just passing in some values, and it just takes care of it. So the things that I found to be very difficult in a system that wasn't based in a CSS and JS would have been something like a grid component that has, like, dynamic grid columns. My grid component in Vercel up tutorials accepts an array of of numbers, and it's how many columns the the grid should have at each breakpoint.

So this is, like, really interesting. So if if my grid component has a columns property of an array with 1, 2, and 3, at the smallest breakpoint, it'll be 1 column. At the medium breakpoint, it'll be 2 columns. And at the large breakpoint, it'll be 3 columns.

That kind of thing is difficult to do in a dynamic way in without something like style components because there's no way to to dynamically run a loop. Right? That's the big things that I'm missing still in CSS beyond, like, things like nesting and whatever. There's no way to do things like a loop, and and that really comes in handy in styled components, especially when the loop is generated dynamically.

So that's why I like styled components. Again, in addition, I just kinda like how

how I'm looking at a card and not a div with a class of card despite how minor of a, an addition that is. Yeah. You know what's one thing I ran into just a couple days ago? I was working on my Gatsby course, and we also had a grid component where the grid component had like a default of 2 columns and a default gap of 20 npm x and a couple other defaults.

So I had a grid on the Node page where I had, like, 2 things. I had, like, a list of pizzas and a list of people, and I wanted to put those side by side.

And I had changed the columns and the I passed in some variable CSS variables, not not style components, but I passed in just regular CSS variables.

And then inside of each of those, the list of pizzas and a list of people, that also was a grid component. So I had nested grid components. And I was running into this issue where the lower level one, and I wanted the defaults to kick in, but the higher one, I wanted to pass in my own. And I was like, what is going on? And I was like, oh, even though I'm passing in the CSS variable at a high level, it's not scoped just to that grid. Node. And any other any other child element that uses the same CSS variable will then inherit that. And then I got into this weird situation where I I couldn't I couldn't really do it. Be I couldn't really use the the default. I had to explicitly pass them in each time because they're they're not scoped to that component. They go all the way down. Yeah. The scoping

I'm working on a course that all it is right now for this month well, by the time you're hearing this, it'll already be out. It's on using CSS variables to do design systems. Like, that's pretty much the scope of the course. And we spent a long time, like, 2 whole videos on specificity as well as scoping for variables because it is it's it's one of those things that when you first start to get into it, you don't necessarily understand all the, the caveats here and there of of using them. So, Mhmm. They're definitely a powerful tool and definitely, just another another way that you can foot gun yourself with specificity in CSS with the cascade and all that stuff.

Next question we have here is from Mandy. What are your thoughts on companies that make senior developer roles require leadership responsibility? A great technical person does not always make a great leader or vice versa.

That's a that's a great question. I think if you are going to be a senior leadership, I think that's kind of in the in the name that you will likely have people under you that have to report to you and have to ask you questions and things like that. And, certainly, I'm sure a lot of people on this podcast can say, yeah. I've I've run into my fair share of senior developers who are hard to talk to and and are are brash and and all that stuff. So I definitely think that that is is key just because in your web development career, having good interpersonal communication, people skills is super key.

So I I think having them as a senior developer is is definitely important. So it it sucks if you just wanna be a Sanity dev dev and just hack away all day. But, unfortunately, that's how teams work.

Yeah. I I think about this, like, there's difference to me between, like, a tech manager and a senior developer. A senior developer to me is somebody who's making, like, project based code.

They're making, like, a lot of, like, I okay. This is what the project should be. This is what our this is what the team should be. And those, to me, are all, like, very leadership esque roles. Like, to me, being a senior developer is not just about being good at Node. Because, like, yes, you can be good at Node, but that that that to me would just, like, put you into a, like, a territory of being a, like, a just a straight up developer. You're not like a junior. You're you're, you know, like, you're a developer, your web developer, a web applications developer, or whatever. But, like, that whole that whole level of senior developer or anything like that to me says that you should probably have some leadership skills. And believe it or not, I don't know if people know this, but, leadership skills are not just they don't just exist. You Node, for some people, sure. Some people, born leaders. That's a thing.

But I wouldn't necessarily say that too many people here are born leaders in this world. And, largely, the people who do good at these roles and the people who become better, senior developers are the ones who take the time to learn about motivation, the ones who take the time to learn about picking the right tech for projects based on teams' qualities rather than just your own. Those those are the qualities that make a a senior developer good JS the is the the additional qualities beyond just being a excellent dev. Right? Because, you know, a lot of times Sanity developers are the ones you get put in meetings, and you get to talk talk about these code changes and talk about these things. And so a lot of times, that's a a thing too. I mean, there's a whole host of developers that I've worked with in my life that if I was their boss, which I wasn't, I wouldn't I would not hire them to be senior developers because I don't want I don't want some of these people in meetings. I I can tell you very straight up, there are developers that I've worked with before who I I would just not anywhere I would want nowhere near those people near our ESLint. Not because they're not a good developer, but because they can't talk about their code. They can't be civil to clients in the right way. They're better as developers. And to me, that doesn't that is not necessarily what makes a a good senior developer.

But who knows? Every every these are all just job titles, and job titles, as we know, are largely meaningless and different between organizations. So I would personally say that you should learn these skills if you get put in that position or if you want to be in that position or yeah. Just be aware that that's a thing. Right? That's an actual thing.

Alright. Next question is from David, comma, London. And I'm not sure if David's name is David London or if David is living in London or if he's visiting London and decide to ESLint the cup. But it's David London. Hey, David.

David says, I'm often Node good at planning out Node from the start. I find it easier to start coding if a few lines, run it and see where I'm at, and carry on.

This technique doesn't work when I need to. Wait for deploy to finish so I can view the results.

Increases dev time. Do you have any advice on what I can do better? Wes, I tried doing TypeScript once and it was a horrible experience because I tried, Instead of debugging my code to try to get it working, I spent most of my time trying to fix TypeScript.

I think it's a a common common thing that people run into. I think this may have to do with my poor code planning. Now I okay. Let me tell you this. I run TypeScript myself. I am a good code planner, but I I'm not always I'm not always choosing to develop like that. Sometimes I choose to develop, like, wherever the wind may takes me. You know, I'm a a leaf in the wind. Just that that's how I develop sometimes. And TypeScript, I don't think it's in the way of that. The problem is is that Type Script does you you do run into a problem occasionally of just trying to get things working. And then by the time you do, you're all exhausted or maybe you never do and you never get there. So it might be better to pick up TypeScript on a project that's working from the start and start with it with TypeScript, just so you can, you know, start at the baseline.

But okay. Let's get into the the actual question, which is, basically, what can David do to improve the time that he has planning his code out? Now here's what I like to do. Your code is largely going to be, if you think about it, it's, you know, it's a procedure. It's a thing that does a thing. Right? And we we often think about our our code in terms of the code itself. It's a function. It's, it's a React component.

And now what I want you to do is I want you to get your comment hands out and and do, you know, the command forward slash into a comment Node write what the component does. Alright? This component plays a video.

Okay. Well okay. So that's step 1. Now let's break that down a little bit more with some more comments. We would say, alright. Well, this component, it needs a video element that the video comes in from this prop, and this does this. When I click the play button, it needs to do this. When I click the stop button, it needs to do this.

When it's paused, maybe it needs to do this. When the video's over, it needs to do this. Maybe it goes to the next video if it's an autoplay thing. Write out everything this needs to do, but do so in a, like, a tree, an outline. Right? Have you ever written a paper for school or something like that? You write the outline, and then you fill it in, and then you fill it in, and then you write your paragraphs.

That's how I write code when I really, really, really want to make sure it's organized.

I write a layout for the code in comments saying explicitly in English what it needs to Deno. Needs to do this, needs to do this, needs to do this. And I'm not thinking about, like, it's a React component. I'm saying, like, on end, these 2 load next video. Okay? Right there. That's describing basically 1 function, and that's describing the higher levels of this. And you can use this structure that you're writing in comments to then write your code within the comments. And guess what? If you do that, your code will be commented without you having to write comments after the fact. A double whammy here. I I use this technique all the time. So I write out my whole organization,

my whole structure, everything the code needs to do in comments, and then I fill in the code afterwards to get it to work. Yeah. I I do the same. It's I call it pseudo code Wes I just we do it in almost all of my tutorials as well. We write down what needs to happen in comments and then fill in the blanks from there. I think also a problem that is coming from this question is this technique doesn't work when I need to deploy wait for a deploy I know that too. I can view the result.

So, like like, that means that he probably has a Node like, there's no local developer experience.

And, certainly, I've worked on projects like this in the past Wes you you make a change, you have to deploy the thing and sit on your hands for 3 minutes and then check if it worked. And then if it doesn't work, you have to do it again. And and that feedback cycle is so frustrating because you, basically, you went from 3 seconds to just refresh and see if it worked down up to 3 minutes, 10 minutes, sometimes even 20 minutes, and Oh, my god. You can't get any work done that way. So it sounds like you need to figure out how to replicate your production environment locally so that when you test something, you can just see the result almost immediately. And there might be some roadblocks. There might be some really long compile times. I know there's a lot of people out there that are still using, like, Ruby Sass where you make a change to some CSS and you have to wait, like, 15 seconds to see if it changed. And that's that's extremely frustrating. So try to find out where is that time happening and how can I make it quicker as well as local? And that will free you up to to have a much faster feedback cycle. Yeah. Fast feedback cycle, very important.

Next question we have here is from John. He's gotten Wes. Big fan, a long time listener. I have a very random question for context. I'm a Mac user and a Linux OS user myself. However, recently, while building our application, I noticed that Windows does extremely weird things with the font size.

JS we have a pretty decent Windows user base, this is something my partner and I wanted to solve. However, I'm unsure about the best way to handle it. It seems entirely different from user to user on Windows.

Example, a company employee on an older desktop font size is set by default to a 150%, while a different employee's newer four k display is set to 200%.

That seems weird.

How in the world do we JS developers account for something that seems so inconsistent? We have tried vertical media queries that are much more or less of a kick to them for tablet mode. That's kind of annoying. Obviously, this is less optimal.

So this is a great question because you you kind of have to think about not only screen size, but, like, resolution.

Because somebody who has a 32 inch 1080p monitor will have things much bigger than someone who has a 32 inch 4 k monitor. And then even then, some people who who run these monitors run the the fonts totally small and some of them run them much bigger.

Unfortunately, that is I I don't think that this is a problem with your code. I think that this is a problem with your users having their their fonts scaled up and down. Yes. I don't I don't think that this is actually an issue with your code because this is you if you use specific font sizes for specific things, they should be all that size in relation to, the rest of the website. So I did run into this as a, like, when I did client work, you would get you get people being like, hey. Can you make this bigger or smaller? Because their specific computer screen was Mhmm. Big or small. But it's up to you to to do sort of a good baseline that is visible to everybody. And if the user is finding that the font size is too small or too big, then hopefully the the rest of the Internet for them is is too big or too small, and they need to account for that on their end. And if it's not, you're probably doing things too big or too small to start with.

So I know that's not much of a a good answer, but it's probably not you, but it's the user.

Yeah. And I'm glad you caught that because when I added this question, that's exactly where my mind went when I read this question was, this sounds to me like somebody has their browser configured a certain way, and that's why there's this huge discrepancy.

And you know what? You just can't account for that kind of stuff. That's the beauty of working on the web JS that there's just too many variables and little things that are going to just exist like that that there there's only so much you can do there. So you can just provide the best experience possible to as most people as possible. And if somebody wants to size their font up and is angry about it, tell them to size their font down. And, you know, obviously, you can't do that to all of your users, but that is certainly a thing.

That's exactly where my mind went when I read this, so I'm glad you Scott on to that. If you want to, you can detect the zoom level on your application.

So if it is an issue where your application is being weird at a different zoom level, you can detect that. But I would almost say, like, don't do that because I always say you don't do it. Yeah. Yeah. Because, like, obviously, your user is zoomed in for whatever reason. Maybe they have a hard time seeing the text, specifically also myself. I I run my monitor at very a very high resolution.

And then I will often just bump up the font size on my browser or in my text editor, just because I want the text to be big, but I don't want, like, my tabs to take up all the space and things like that. Yeah. And, also, like,

accessibility, you know, there could be very real reasons. And and me, personally, I I used to not feel this way because I didn't understand assess pnpm I don't know what I'm saying used to. I mean, like, back before I understood what accessibility stuff was in general. But, like, I used to just, you know, outline 0 or outline none. And then once I realized just how terrible of a, of an idea that was, I've just largely always erred on the side of, not messing with anything that the browser does for accessibility. If the browser is doing it for accessibility, you're probably not going to be doing it any better, and you're probably going to be hurting some of your users that are using it for those reasons. So

there's 2 things that people always say on Zoom level. 1 1 person says don't use percentages for things like font size or margins or whatever because when you when you bump up your font size on your they won't actually increase it. And that has not been true for a long, long time. So stop saying that. Every time I I tweet anything out, I get 1 person that says that. Wes funny. Always talk about that. Yeah. That hasn't been true for, like like, 6 years or 7 years now. Yeah. Because what the browser does when you zoom when you used to hit command plus in the past, it used to bump up the font size. Now what it does is it increases the browser to the zoom level. Yeah. That's that's a really good point. And, yeah, it got rid of a whole bunch of issues that came along with that. The other thing is that if you're doing font size based on, like, a VW, like viewport width or viewport height, fonts that are set based on viewport height or width, When you scale them scale up the browser, the fonts actually don't adjust themselves because there's still a percentage of the height or width of the viewport, so they don't bump up. And to get around that, you can use a calc. So you can say, like, calc 10 v w plus 10 p x, that will convert it to a pixel value, and it will go up and down as the the browser zooms in and out.

That's one I didn't know about. Someone just on Twitter might be, like, a month ago said it. I was like, oh, interesting. That's good to know. Man, yeah, Twitter's great for that stuff. Twitter is a good place, usually. Sometimes, it's awful. Yes. Exactly. Sometimes.

So next question is from Dury Puncher. Dury says here, are side projects common among developers? I recently mentioned to my boss that I have a few side projects and nothing serious, just for learning mostly.

And he said he would rather that I didn't and instead focus on my work. Oh my gosh. He said he hadn't really heard of developers doing side projects and that if I wanted to work on things that aren't our at work, that I have things that he has things that I can do. Oh my gosh.

Yes. Okay. So yeah. So this one's tough because okay. If your boss has things that you can do and there's work that's not being done, yeah, don't do side projects. If there's literal work to be done and you aren't doing it because you're working on your side project, that to me is a valid reason for a boss to say that. Right? That that that's totally valid. Yeah. If you're on the clock. Right. Only work on side projects on the clock if you have the, blessing of your boss or if they won't find out.

So, like, I don't just be like, hey. I'm working on this side project, boss.

Me, personally, every time I did work on a side project, my boss either knew about it or would not know about it because I was so ahead of my work, and he was so checked out that they would never have figured it out or something like that.

I would recommend if you are doing this kind of thing to talk to your boss and let them know that you would like to spend time learning and working on side projects because they will make you a better developer. Give them the whole pro pros and cons for doing it, but don't just do it and then talk about it as if, you know, they might be mad about it or something.

To me, this seems like there is valid reasons for a manager or Bos to be bad about this. But, again, the Bos' attitude here is also kind of weird. Like, pnpm do developers work on? That's how you learn stuff. What are you talking about? That's how you learn. Yeah. You learn by writing code, and you write code not always in your projects.

You Sanity write experimental code in all of the the work that you're doing, so how are you expected to learn? There's a lot of red flags here to me, but also just make sure you aren't making your boss mad by not getting the work done, if there is work to be done. I have heard many times people work on side projects

on the clock, and they they will own that code because that's probably part of your contract. So if you, like, stumble upon some, like, $1,000,000 idea, they will own it. So I know a lot of people strictly will not even touch a line of code while they're at work. But there are there also is people that have contracts that say, like, anything they do at any time is any line of code. On that machine, on the work machine. Or Yeah. Scott sure how legal that is or not, but definitely check it out. It sounds like your boss just doesn't understand. I would just tell him, hey. I'm making mistakes here, so I'm not doing it in our own code base. I'm learning, stumbling through things. And, also, like, it's fun. Like, you can get real burnt out at work real quickly if you're working on the same code base. Oh, yeah. And being able to have another side project that you're you're tinkering away on will sometimes bring that love back.

Can I also say here, I Node already said a lot about this one, but, like, that side projects that you're working on at work, the, to me, the the sweet spot for a side project that I worked on at work was always involving something that if my boss asked me what I was working on, he would be psyched about it and not, like, upset about it? For instance, when I wanted to learn Angular at one of my jobs, if he would've walked by, he'd been like, what are you doing? I would said, I'm making a prelaunch checklist for all of our projects.

And he would've been, oh, wow. That's a really cool thing. And then I'm not like, oh, it's just some side Scott I'm working on. You know? This is like this is a learning experience. This is a project, and it's something that's going to make our team better in some sort of way, and that still checks all the boxes of being a side project. A side project doesn't have to be like a Pokemon thing.

I'm not saying that yours is. I'm just saying, like, it it should be probably something related to your warp, and you can and you can your your boss will love that if you're if you're thinking about those kind of things.

So for all these side projects that you are working on on your own time, because maybe these side projects are gonna turn into a business, maybe you got users on these things. And I'm talking about side projects that are off the clock, you might wanna go ahead and throw on some error and exception handling tools. And I mentioned that this one plays really nice with our previous sponsor in early on in this episode, Lock Rocket. And I'm talking about Sanity at sentry.i0.

Yeah. Sentry, they just got a new tagline on their website. Software errors are inevitable.

Chaos is not. That's that's a that's a great thing because a couple weeks ago, I do I I said this earlier. I deployed a new checkout.

Not a new checkout, but a couple new, like, major changes to it.

And something broke. And that could have been chaos because I could start losing money.

People are emailing saying, hey, it's not working. But I was able to jump into my Sentry, see the errors that were happening, kind of see the stack traces, the browsers that it was happening on, and and really quickly pinpoint where the error was happening and what code was was making it happen.

And I was able to jump in. And actually, in in my case, it was that there was a cache of the old version. So it was showing me the error. And I said, I can see that that's not the right code because I had written new Node, and I'm not seeing that in my Sentry. So I was able to quickly jump in and and unvalidate that cache. And that would have been very hard for me to debug because I had I had cleared the cache in my browser, and I wouldn't be able to replicate that in my own browser. So having that sort of insight into how these things happen is key. And that's why you need Sanity for your project at century.

Io and use the coupon code Sanity treat, all one word.

And that's gonna get you 2 months for free. Thanks so much to Sentry for sponsoring.

Let's get into some sick picks. Do you have a sick pick today?

Sick pick? Yeah. Sick pick. I got a a sick pick today.

You know, I I sick pick a lot of podcasts, and some are a little bit more, like, a wider reach than others in terms of who's going to be interested into what.

But there's a really neat podcast that I've been listening to along the same lines as Darknet Diaries for a little while now, and it's a malicious life.

And it's it's a little bit less of a drama podcast than, than Darknet Diaries, and it's a little bit more of, like, explaining situations. For instance, he spent 3 episodes, which totals about an hour and a half on the Stuxnet virus, and he he talks a lot about these different things. He talks about a lot of different worms, and he runs down different situations and then really, like, just dives into it. The show's very good. I've been listening to it now for quite a while here. Yeah. Just one of my favorite cybersecurity podcasts because it really just opens your mind to some of the stuff that's going on. And like I mentioned, it's a little bit less Wes, like, a a narrative dramatic form than Darknet Diaries, a little bit more, like, straight up. And it it pairs really nicely. I think even, Jack Rhysider from Dark Knight Diaries was, like, a guest on one of the episodes. So Yeah. They've done a couple swaps. Yeah. They've done a couple swaps. But let's just say I know this JS so funny because, apparently, I'm about to rob a bank, and I'm about to scam people because I I, like, follow a lot of swindlers and scams and and hacking. I like those podcasts. Me too. Those are definitely my favorite podcasts, Sanity, fits right along in that same same world there.

Yeah. I I have been listening to that one for a while. The only thing I don't like about it is the the host's intonation JS he I think it's his I think it's ESL. Like, he probably speaks German and and whatever, and he takes the intonation from his language and and brings it to English. And as a native English speaker, I'm like, oh, that's a little bit off. I I know it's not something I should be worrying about, but sometimes it gets to me. Yeah. It doesn't bother me. It's not something that I've ever but I I can understand why it would be make listening to it a little bit more difficult because it's not, like, as seamless or something. But, no, I, you know, I I I totally get where you're coming from. The content is worth it, though. It's it's, like, super well researched, and it's it's very technical too. Like like, they don't dumb it down for for anyone. So I I really appreciate that. I'm going to sick pick my new hard drive. So I have had these Western Digital Passport drives for a while. We've Scott, I don't know, I've got like 3 or 4 of them just for I got Node for kids shows. I got one for Time Machine. I got another one for my wife's Time Machine. We have a handful of them. And I recently accidentally just drop kicked 1 off my desk. I had a a cable hanging, and I kicked it. And it the whole hard drive went flying while it was spinning, and I I killed it. Can I say something really quickly before you jump into this? Time machine. You you and your wife's time machines.

It's just funny that that's a sentence that you can say in, like, in in English, and and, like, everyone's just like, oh, yeah. Our time machines. And we all know it's not literal time machines. It's just, like, funny to say. No. So if my wife and my we use these these hard drives for our time machines.

It's the secret. No. The obviously, the backup of your computer.

And, I have, people always ask, like, why don't you use what's the thing, the Synology for for that? It doesn't work well. Time machine doesn't work well over over the network. So really doesn't. And I I much rather just have, like, a physical USB for my time machine. Anyways, so I kicked 1. It broke. And I said I said maybe I should try a different one because I think maybe that's the second one that that went on me over the last, like, 7 or 8 years. So I went for the Laci rugged one Wes you've probably seen this. It's like a bright orange neoprene jacket or rubber jacket around it. Like a life jacket. Yeah. Yeah. And what I really like about it is that it's just USB c, and it's besides my iPhone, it's the first thing I've bought that comes with a USB c cable out of the Bos, and you don't have to have some stupid connector for it. It came with both USB, actually, which is really cool. And I was like, man, after, what, 5 years of having a this MacBook, this is the first thing I bought that I can plug in to it. Mhmm. And it feels good.

It looks like it will survive a kick unlike the other ones, so, I'm pretty happy with it. And it's also fast as heck. I think it backed up much faster than the other one did. And the other the the Western Digital My Passports, they come with this, like, weird USB c or USB 3 plug that's, like, 2 prongs in 1. I'm not sure what the name is is of it, but you know what I'm talking about. And, like, if you lose that cable or you you forget that cable because, like, we have it for our kids show and I often will bring that kids show hard drive with us wherever we go so I can plug it in a laptop. And if that's if I lose that cable and pooch, but all you need here is just a USB C cable.

Although USB C cables are a a beast of their own. Yes.

Cool. Yes. Let's do some shameless plugs. What do you got for me today, Scott? Yeah. I got a a new course on CSS design systems using CSS variables.

It's really cool. In fact, we spend the entire, like, 1st bit of the course, and I mean, like like, legit first bit of the course. It's quite a bit of the 1st bit of the course doing only classless CSS.

And I'm not talking about, like, this this CSS isn't isn't pulling up at 711 with flip flops on and no shirt. I'm not talking that type of class list. I'm talking it's not using CSS classes.

So we're just styling everything in, like, a a full on design system using CSS properties in straight up elements for CSS to build our own sort of baseline CSS, and then we go from there to build out a full on system and talk about, strategies for dealing with elements and reusability and media queries and all sorts of fun stuff. You can get that at level up tutorials because I gotta tell you where you can get it. Leveluptutorials.comforward/prosign Wes to for the year and save some cash. Thank you. I'm going to shamelessly plug beginner JavaScript

.com. It's a fun exercise heavy approach to learning modern JavaScript from scratch. So it's for, it's beginner friendly, but it goes all the way up to intermediate concepts and whatnot. Gets you really good at JavaScript. Check it out. Beginner JavaScript com. You can use a coupon code syntax for an extra $10 off. Sick. That's it for today. Thank you so much for tuning in, and we will catch you on Monday. Later.

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.