Potluck - Mobile First × Arrow Functions × Deno × JSON APIs × Refactoring Tips × More!

and a potluck lined up for you. And, potluck is the episode where we take in your questions, and Scott and I attempt to answer them. If you have any other questions that you'd like us to answer on a potluck, make sure you go to syntax.fm and click the button that says ask a potluck question.

Those keep us going. We are sponsored by 2 awesome companies. 1st 1 is LogRocket, and 2nd is FreshBooks.

We'll talk about them partway through the episode.

How How are you doing today, Scott?

I'm Dylan.

You Node, everybody, just, making it happen. Like, last night, I just, like, took a Deno, deep exhale and was like, holy cow. I am tight. I'm just, like, tense, man. I'm just yeah. It it's just it's just nonstop, but, you know, it's all good. I, sliced off the tip of my finger the other day, so that was pretty sweet. With what? You don't even wanna know. A mandolin? No. A a, like, actual shaving razor. It was just I was just moving it, and it Oh. Yeah. My nightmare. Dude, it's it's seriously it's gnarly. So, it has been covered. And, yeah.

Not too happy about it. You're not going to the hospital for that, though, are you? No.

I don't wanna get into any of the gruesome details, but it's fine.

Okay.

There's a lot of people who do not want to hear,

what exactly happened to this. So yeah. No. I get I'm, like, almost passing out as you're telling me that. I get so queasy. I get what's called I thought this was a common thing, but I call it the melts, where if you start talking about blood and and veins and stuff like that, I just get, like, oh, and I can't, like, I can't rip anything.

You're just you're you're actually passing out is what it is. You know, it's funny. I, I had a, like, a sister removed from my arm at some point a couple years ago, and they were like, do you wanna watch? Because it's obviously here. You can watch. And they're like, obviously, you don't wanna do this if you're prone to passing out. And I was like, I've never I mean, I passed out once from something else, but, like, I don't I know I never passed that story on the podcast before. Right? I've never I've never passed out. I just need to find to watch this, and then then I'm watching them do it, and I passed Scott, and they're like, oh, you should've you should've not watched. Like, why did you say you wanted? They were actually mad at me for choosing to watch.

I've never passed out before. It's a weird thing. You get, like, a cold Scott, and, yeah, it stinks.

Oh, man. Alright. Let's, let's get into the potluck questions.

First Node we have here is from Simon.

Hey, Wes and Scott. Thanks for the badass podcast. Humor and knowledge always as always, I was wondering on your take on mobile first design and implementation. Node you throw desktop styles or the mobile styles into media queries? Any opinions about that? I'm switching a lot between project to do it differently, and it really makes my head melt. Keep up the good work. So this is a question that we get all the time is is when you are building a website, do you start with the mobile website and then use media queries to it, or do you build the desktop website and then go smaller, smaller, smaller and it? And, a couple Yarn ago, there was a big push for the sort of mobile first, and now I don't know. Like like, what are your thoughts on this, Scott? Like, what do you do? What is Vercel up touch? Is it mobile first, or is it desktop first? Yeah. This is a good question because I think you could really do it either way if we're being entirely honest. And I

have probably not done a good job of doing mobile first specifically because our users are primarily using the LevelUp tutorial site on their desktop computers or their iPads.

So we're inherently going to favor a little bit wider of a viewport. Yeah. That said, the design was certainly coded in a way where it's going to do the most it can to scale up JS in I don't want to have to change a ton of stuff between mobile and desktop.

And I'll definitely do my breakpoints as being the mobile first style breakpoints Wes you only use breakpoints to style things at increasingly larger displays JS in, you know, the default styles are all for mobile. But so many of our styles are set up to a way that you don't even have to think about it too much, too much, too much. Yeah. Hey. It's almost like the media queries are used as patches to fix the stuff that's not working when you make it wider rather than really thinking about the 2 designs as being that separate.

Yeah. Yeah. Totally. I'm the same way as well. I've always done desktop first and then gone smaller. I think the benefit to mobile first is that, I think a lot of times people build these really complex websites and then they find themselves trying to figure out how do I cram this thing down into something that is acceptable on mobile where Yeah. Mobile first JS, like, you think about the experience first on mobile, which a lot of websites are probably majority of it is consumed on mobile. Mhmm. And then you can make it more complex with media queries as you go on up.

Quite honestly, I have never had a problem going either way, so I don't think that, it's too much of an issue. I know that when this first came out, there was a whole, like this tends to happen with, like, everything. Like, this new idea comes out, and then the other thing is immediately garbage or an awful way to to approach it. And I I don't think that's true. I've never had real issues, especially with Flexbox and Grid and, thinking in terms of components and how big that component will be. Like, I think component queries or, element queries will make this the thing of the past as well because, like, I don't necessarily think in terms of website. I think in terms of, like, player and Right. Exactly.

Like, listing of videos or,

pricing grid or or whatever JS on the website. So if it's making your head hurt, then just go back to the other way. I think it's it's totally fine. Yeah. It's totally fine. And, honestly, I have some thoughts on why I think that it's seen as sort of a or or it was seen as sort of a bad practice for a little bit to do desktop first. I think it's because a lot of mobile sites were very neglected at that time. Yeah. Right at that time, media media queries had just come out. People didn't really know about them that much. I mean, responsive design, just become a thing. So all of a sudden, there was like a push to get people to actually make mobile looking websites a priority rather than just an afterthought. So to me, mobile first was a shift into thinking about mobile websites as being something more important than they were before.

Yeah. Because, also, like, what was popular, unfortunately, still is, is that people would just start to hide stuff. Yes. Yeah. Like, oh, it's the mobile website. They don't need all the features, and that's so frustrating to me to to get a website that just hides stuff on mobile Yes. When the reality is is you should start all of the functionality and all of the content on mobile and then and then figure it out. So that I think there's some some good ideas behind that. And as long as you can keep those in mind, you're you're gonna be in good shape.

Yeah. And the only time that's really acceptable is if you have duplicate. Like, for instance, we have a navigation that just straight up does not work structurally between mobile and desktop. So we have a mobile nav and a desktop nav. That's the only actually instance where we have a mobile component or desktop component. Oh, yeah. As long as it's, like, duplicate

content rather than I often find myself going way overboard on, like, clever CSS hacks and stuff to to make it work on both. And then I just kinda, like, sit sit in my chair and go, like, what am I doing with my life? Like, just make Yeah. Just make 2 navs and hide 1 and show the other. We probably had, like, 4 or 5 iterations of our nav that warp garbage

CSS wise because of that.

It's just like, this is too much. What are we doing here? Next question is from Christian Anderson. Says, hi, Scott and Wes. Love the show. Here's my question.

What is the difference between the ES 6 arrow function and a normal function? When would you use a normal function instead of an arrow function or the other way around? Stay tasty.

Christian from Denmark.

Yeah. Stay tasty.

Yeah.

So the big part of this is really how it deals, with this and variables.

Everything else is sort of, I I guess, a lesser function of this where, you could use an arrow function for readability and those aspects of it. For me, I personally prefer the what do you wanna call this this this, simplification of of how it handles this? There used to be this I'm trying to find a good way to explain this without.

There used to be this technique where if you needed to access this inside of a normal function, but you didn't wanna access that functions this, You wanted the parent scope. You wanted the parent scope. That's a perfect way. That's the exact word. You wanted the parent scope. You had to do this whole this equals that or this equals parent or whatever beforehand in the variable and pass that in.

And it was such a giant pain in the butt because each function had its own scope, where with a arrow function, it doesn't have its own Scott, so this would refer to its parent scope. So that's largely the reason why I use it. To me, it's more predictable. I don't have to do this whole this, that dance to access the parent, and it largely to me, it looks cool. No. I don't know. That that's that's low on the totem pole, but I do think it looks cool. Yeah. It definitely does. So arrow functions

do have their own scope. They just don't rebind the value of this to that that function instance. So it will be inherited from the parent.

And if there's no parent, this then they will go for the parent of that, and then eventually, this will just be the window if nothing is bound to this. But if you create variables inside of an error function, you still will those will still be scoped to that function.

So what what else do they do? They they allow for implicit return. So, if you're doing, like, a map filter reduce is probably the use case where I use an arrow function most often, where you just need to take in an argument and then immediately return something, like, divided or or looked up in an object or multiplied by a certain number or or filtered out, return true or false, those quick little things can be done on one line with an arrow function, and that is that is huge.

Implicit return is not doesn't have to be. You can still return and use curly brackets on an arrow function as well. It's just kind of a shorter concise syntax.

The other thing about arrow functions that they must be passed in as reference or stored as a variable. So a function declaration where you actually write the word function space, say hi, that is that's called the function declaration.

But because JavaScript works in a way where you can put functions in variables, that that's why you can do something like const say hi equals function as well.

The arrow function is can only be passed in as reference, meaning passed in as an r an argument to, like, a map filter reduce, or it has to be stored in a variable. So they're technically anonymous functions, but that doesn't really all matter all that much because if you have, like, a stack trace or something went wrong, it will usually take the name of the function from the variable that it was stored in instead. So, yeah, it's it's kinda interesting.

When they came out, arrow functions, people were like, I'm gonna use arrow functions for everything. And, like, I would get a lot of people being like, why are you using a normal function? Like, why don't you upgrade that? And, like, I certainly do use both of them.

I don't use the this keyword a whole lot in much of my programming anymore just because that's more object oriented. Functional allows you to sort of just take in arguments and whatnot. So, like, what do I use? I use both of them. For React components, I've actually switched away from arrow functions and over just to regular functions partly because of hooks, partly because of the implicit return was such a pain in the butt to debug. Yeah. Yeah. And so I I just switched to to just regular functions. So that's the difference. They're both very useful.

Use an arrow function if you need the this to not be scoped or you need the concise syntax.

The reason why I use the arrow function, like, all the time and I just do I force explicit returns. Well, for the most part. I don't know. There's there's some use cases where I don't do implicit returns.

But there are like, for a React component, always explicit return every single time because you will need to refactor that. And, I to be honest, arrow functions all the way. I pretty much only do arrow functions, and it's really just for consistency in both syntax, the visual of it all, just to have things be parsable, but also just so that we always know how things are functioning. And not to mention, we just about never use the keyword this.

So, I don't I just don't have to think about it too much. That's not a a big, a big issue for you. Yeah. Next question we have here is from Max Dayton. Hey, Scott and Wes. What are your opinions or experiences on developing for 3 60 slash VR experiences on the Wes. There are few frameworks out there like A Frame and React 3 60. I was wondering if you had any experiences building with these things.

And do you think this could become a big thing for the web development in the future? So I know I'm gonna pass this over to Scott because I've never done anything in VR. I've put a headset on once, and it was pretty cool, but that's that's where it stops with me. Yeah. So this is really funny. I've been since the,

the, snowbreak thing, the snow snow day, the current situation, I I've been playing a ton of VR for, like, an hour each day, I would say, maybe. It's it's been really interesting for me because it's like Wes put the kids to bed, and there's, like, a little period before Courtney and I are, like, really hanging out. We're all just sort of floating around, and I have been playing, VR table tennis, which is not something that I've ever played, really.

And I feel like I could be decent at table tennis now because of all the time I've put into it in. The physics are so good, and I absolutely love it. So I am becoming a huge VR fan in that regard.

The one thing I hate about VR is being, like, tethered to a computer.

So my unit is the Oculus Quest, which just says no cables or anything. So as long as you're not tethered to a computer, I think VR has a lot of possibilities. I think as long as you are tethered to a computer, I don't think it's going to get that sort of mass adoption. So what are my thoughts on WebVR? I think it's fantastic. I think it's interesting. I think it's so cool. I've never heard of a frame. I have used, React 3 60 briefly.

Nothing any major, to create anything major. It's one of those things that if I had any free time to do a goof around project, I would definitely spend it on Node of these things. Not because I the more I find myself using my own VR headset, the more I I get ideas about what kind of cool interfaces you can build in it. So I think it's very interesting. I would love to do rather than like a game or anything like that, I would love to build some sort of interactive video experience where you watch a tutorial in some sort of way that makes it more interesting.

Either way, I I would keep an eye on both of these platforms. I would try them out if you have the capability of trying them out. They look so stinking cool, and to be able to do VR using React components definitely, is a plus for me. Not to mention, since my headset is made by Facebook, I would have to imagine that at some point, maybe React 3 60 becomes some sort of an official way of building types of apps maybe. So we'll see. Who knows? Maybe you can take those skills and and really, flourish on a medium that is still very young. Right? We have to consider that this VR medium is very, very young, and there's just an endless amount of opportunity to have a killer app and some sort of variety where you can get in on the ground floor now before these experiences blow up and everybody's got a headset on. And we're all floating around on movable chairs like Wall E.

Yeah. I am more interested in the AR, which is augmented reality. And I imagine you could probably do something similar with these frameworks as well where you're overlaying useful information on top of, whatever it is that your your camera is seeing. So maybe that would be a fun project to do as well. Maybe just do, like, a simple little, like, detection, grab people's faces Yeah.

Maybe pop up information. I I always take the Instagram. Have you seen those, like, the couple's questions on Instagram lately?

I've I've seen a bunch of, like, the quizzes and challenges, but I haven't seen the couple's questions.

Oh, it's like it's kinda like Wes you get married, you play the shoe game or, like Yeah. Who's most likely to cook dinner? And you put the shoe it's it's like that. But instead, you you tilt your head left or right, which is pretty nifty. Oh, that's fun. We should do. Yeah.

That would be a fun little thing to to recreate.

Yeah.

I think they're Like, I'm trying to think, like, how would you do that? Well, like, you would, like, track people's faces, which you can do. Yeah. You do object tracking.

Yeah. You can do that in GitHub in Chrome already. Yeah. And then you just, like, you track where their heads were and then over, like like, I don't know, one second. And if both heads move to the left or to the right or whatever, then you could you could say, okay. They were here, and now they move there. It really doesn't seem that difficult when you think about

it's just tracking

a a value. A box. Yeah. If if the value goes left or right. Somebody make this with the, I've got the face detection code on my beginner JavaScript, repo. It's on GitHub. You can grab that as a starter, and then take it and run with it.

Yeah. Do it. Alright. Next question is from Goran.

How would you define senior developer? What's the difference between an intermediate and a senior developer? As somebody who has had the senior developer role in their title before, I can tell you it's largely just a job title.

Now in every single organization, these are gonna this is gonna mean something different, which is one of the reasons why I think it's kind of a vanity thing.

Sometimes Wes you you are applying for a job, the senior developer position, all it means to the employer is that you've been in a role where you're doing a bit more management and you've had a little bit more on your shoulders, a little bit more pressure, a little bit more ownership.

Me personally, when I became a senior developer, I had a lot of different roles that I didn't have before. I was supposed to go to more meetings, more management meetings, more meetings where I had to be the spokesman for all of the developers, right, the advocate for the developers.

And this is a small company. Right? It depends on the size of the company. I was in charge of coming up with the workflows that we would maintain as a team, the git workflows, those types of things. I was in charge of directly managing the developers, their timelines, their projects. And I was also in charge of picking our stack choices and even giving maybe some other developers more freedom to choose their own stacks based on what their comfort was. But again, this is largely something that's going to be different in every single organization, and simply having the job title of senior developer is largely just going to mean that you've been in a position of sort of management or heavier load and responsibility as a developer.

And, if you wanna make sure your website's capable of handling some sort of heavy load, you'll want to make sure that you have some sort of error and exception handling service, one of which Wes you can see how the errors are happening. Now this sponsor, of course, is LogRocket.

Now LogRocket is the error handling tool that allows you to see how your bugs happen. You get a session replay video that is so cool. You could scrub it. You could see the network requests, the error logs, the Redux store, anything you got in there, and it works with all of your frameworks that you know and love. You can even see where the user clicked to turn your website into a frog. How'd they do that? I don't know, but you can find out with LogRocket.

So if you wanna check it out, head on over to log rocket.comforward/syntax, and you will get 14 days for free. Check it out.

Beautiful.

Next question is from Jason.

Hey. I was curious about knowing your opinions regarding JSON colon API and its consumption in React.

Is it still a good pick going with JSON colon API or, compared to GraphQL or just a normal Wes of JSON API? So I was, like, reading this. Like, what what is JSON. Colon API? API.

I thought, like, that's just a regular REST API. And and I looked it up, and I said, oh, okay. So this is a specification for building APIs in JSON. So one of the downsides to just getting an object, JSON it and sending that sucker down the line JS that there is no standard for how you should interact with it, for how to structure your data, how to do pagination, all of that stuff. There's no specification for it. So everybody sort of just invented their own way of doing JSON APIs. And every time that you needed to work with an API, you basically had to kinda sit down and and figure out how that thing worked. And that's still somewhat true with GraphQL because you still have to know what the functions are called and what they are, but we we do have standards in GraphQL for pagination and edges and ownership and things like that. So it looks like this JSON API is just like a spec for for building, APIs, and, it's been around for since 2013,

been last updated. I've never heard of this, and I don't know why I've never heard of this. No. Me neither. But yeah.

So, honestly, all of the jay JSON APIs I've built in the past, I've never had a whole lot of problems with it that I I needed a a rigid spec for this, but I could definitely see someone who was building a much larger API could look for something like this.

That said, if you are building an API from scratch right now, I probably wouldn't go for this just because I think GraphQL is probably a better choice, if you are going to build such a rigid API and not just a standard, like, JSON stringify it, give it an endpoint, and call it a

day? Yeah.

I do think that having some sort of a structure or some sort of a a spec is a is a good idea for any sort of major organization.

It it's funny that the APIs that we largely write are consumed by only a few people, and I think that's a a big difference between needing something with some sort of our rigid spec and being able to come up with a little bit more creative spec of your own or something. To me, personally, I am using GraphQL, so I haven't really thought too much about it. There is sort of like this counter pushback to GraphQL going on right now. I don't know if you you've seen it Wes people will be like, you probably don't need GraphQL. It's probably just as good to do this and this and this. It's like, okay. Cool. But I like GraphQL still. Like, that doesn't mean I don't like it because, I I do like what it what it gives me. Have you seen this whole, the GQLESS thing? It is called the GQLESS.

GQLESS Scott is the site. A GraphQL client without queries. It's so cool. It's pretty cool. What does it do? So, basically, here here here's the gist. So for those of you who don't know, with GraphQL, what you do is you basically write an object like a pseudo JavaScript object.

And GraphQL, your API, gives you back everything you ask for. Right? Well, what this library does is it takes it 1 step further, and it says, hey. We know that your component is using GraphQL, and so you can just start using properties within your your React component or whatever. You just start using properties.

And what this library is able to do is sort of pull out the object structure from the things that you're requesting and build a query for you so you don't have to write it for yourself.

It makes so much sense. And then, therefore, you're never gonna have to worry about stuff.

There's, like, this often this this disconnect where maybe you forgot to query something, and you just thought it was available to you. So you used it, and then it wasn't there.

And then that can cause a bug. So this is a really interesting new library. And by new, I mean, I think this thing is brand new.

And, I haven't had a chance to use it, but I've seen people talk about it. And it's been up for a little bit here, and it already has, 2,300 stars and a bunch of forks. And it looks like it's well underway to becoming really super cool.

Yeah. Because, like, also, if your GraphQL or Scott, if your GraphQL API is typed Right. So you can just start coding and it will know all of all of the properties and whatever, and you can get really nice autocomplete in your template. So you just you just, like, use the data in your templates, and it will figure out how to query that for you, which is pretty nifty.

That makes so much sense.

Yeah. I'm I'm interested. I I definitely am interested, and, it makes a ton of sense. I'm very excited for trying this out at some point. I wish I had, like, a little little tiny project to try this out on. This would be a pain to try out and level up, but definitely looks cool. Something to keep your eyes on. One more thing about this, JSON API is they have a I'm just on the website here. They have a recommendations

page about how to how to camel case things. You your API should start with a character.

Here's the URL structure you should use. Here's the URL structure for a single piece of item. Here's how you get comments that are relationship to something.

I like that a lot. That's very much like, when I learned idiomatic JavaScript where, like, just give me a page of things I should and shouldn't do, and I'll follow that. Nice.

Yeah. I like that. Alright. Next question is from actually Jason.

Not Jason, but Jason.

And Jason asked 2 questions here. I thought they were very related, so I decided to, answer both of them here. What's your take on Blitz. Js? Would you use a framework like this to build large and scalable web apps? And then, also, what's your take on Redwood JS? Would you use a framework like this to build large? It JS the same question with a couple of words replay. So for those of you who don't know or feel fatigued by all this stuff, you're probably rolling your eyes that there's another another new dot JS thing. We have Blitz JS, and we have Redwood JS. Now both of these are layers on top of the things that we're using currently, like React, GraphQL, whatever.

They're sitting on top, and they do specific jobs. Now I have an eye on both of these projects because I think they're both interesting. They're both fascinating, and they both fall into this category of things that we've continued to predict on this show that are going to become more of the future of this platform that we're working on. So it's funny that Wes we've So the first one, Blitz is more like a Rails competitor. Right? Well, not a Rails competitor, but a Rails analogous.

The whole thing about Blitz is that it's a monolithic platform JS in you're writing your your entire code base in 1 code base, but it uses serverless functions. So when you deploy, it's all serverless, but I don't think you have to worry about that aspect of it too much. Isn't this the the same framework we talked about a couple episodes ago? It is, but things have been moving along here a little bit more. Clearer what it is now. Definitely more clear. So Blitz, in short, is trying to be the rails for JS. Now Redwood is also taking this, but it's taking more control over the data side of things, and it uses React, GraphQL, and Prisma for the data. So with this one, you're not having to think about a database or your schema, and it's trying to encompass all those aspects and then just giving you React. So I have my eye on both of these. I think they're both cool options.

I think my meteor stack does a lot of this stuff really well in the same regard. Like, I have server side rendering, code splitting, GraphQL, all those the same stuff. Right? So I I think that I'm gonna throw modern meteor into the mix as a a nice option here too, but maybe a little bit less handholdy.

I don't know. We'll we'll see about these things. They're brand new. And, largely, they're saying, would you build anything in this right now? I'm not gonna build anything major in either of these right now because they're I don't even think either of these are done yet. So just keep your eye on them and and see. Maybe that could be a cool opportunity to, learn something new here. Yeah. I would definitely

use this for a weekend project, but nothing too serious just yet. And I would definitely keep my eye on them because these are 2 things that have the potential to become really popular.

And if you can be on the Scott front of that with blog posts or YouTube videos or whatever, then that's a huge because, like, I Node of these 2 might be it. Word.

Next question we have from Andre MacNamara.

Is that right? Yes. I did butchered it, like, 3 times before this. MacNamara.

What do you think of Deno JS reaching version 1 ESLint o? Is it really going to be a node successor, or is that just marketing hype? So Deno, we've talked about it a bunch on the episodes before, but basically what it is is it's a a runtime in JavaScript and TypeScript, that's built on the same engine that Node is built on, which is called v eight. V eight is also the it's it's the engine in Chrome, and and that's that's the reason why we're able to have, Node. Js in the 1st place is because you can take an engine and and run it in different places. So the idea behind Deno is that you can run the whole thing in TypeScript.

What are some of the other benefits of it? We talked about so many times that just

there's a lot of things where you, like, where you declare your import as being from a repo specifically rather than via package dot JSON file.

Oh, yeah. Yeah.

So that seems pretty pretty interesting as well. Is it going to replace Node? Certainly Scott anytime soon, but from the folks behind it JS well as the fact that they it's like a 1st class TypeScript support.

I definitely think it will be a huge thing in the next couple of years, especially if we can get I'm not sure, like, what does it look like for using an existing node module in Deno because, like, there there definitely have to be some sort of transition there because it takes years to build up all the resources that we have in Node land.

But I'm pretty excited about it. I still haven't built anything serious in it. Just a couple little hello worlds here and there. But, like, begin, we've talked about them before. They support Deno right out Bos the box, which is cool. So there's already, like, a good hosting. Like, that was that was, like, a hurtful thing when Node first came around. It was like, how do I even run this thing on the server? But that whole story looks a lot nicer right now. So definitely not marketing hype. I would say Deno has anything but marketing.

They're they're Scott, like there's not a company behind them. There's not a whole bunch of, like, VC or anything. I I don't think there is at least. It just seems to be a bunch of really smart people trying to solve something. I mean, if I think, like, a couple episodes ago or maybe a couple months ago, we said, it was built in TypeScript or or we mentioned that and it got put a couple people got mad. It's not built in TypeScript. It's built in Rust, but you you build your apps in TypeScript. You don't build the apps in Rust. So, what the thing is built in under the hood, we as developers don't necessarily care all that much. Right. Yeah.

You Node, so it it's funny that I, I don't know. I'm interested in Deno. But at the same regard, I'm I think I'm interested in it the same way I was in TypeScript about, like, 2 years ago. Right? Like Yeah. I am keeping an eye on it. I'm thinking about it. It's in my brain space, but I'm not going to, like, really dive in or really do anything unless it, like, really picks up. For me, like, there was some point when TypeScript became the obvious champion. Right? Yeah. Reason now Wes the other Node, Flow. Yeah. I don't think people people like Flow very much.

And so TypeScript, like, very clearly became the dominant of the type systems for JavaScript. And at that point, I was like, alright. I have to invest the time because this is becoming an industry standard to know cursory glance at Deno just to have it in my brain space.

Next question is from Deno, the man. Hey, guys. Love the show. My question JS, if you are looking to refactor code, do you have a process that you'd like to follow? I've been polishing up a project from a boot camp I attended, and I'm putting on the finishing touches. And I'm getting frustrated with how inefficient, hard to read, and junk some of my code is. I want to go and restructure a lot of things eventually, but I'm wondering the best practice I should be aware of or just maybe a way to tame this beast.

Alright. So I have a couple of strategies for refactoring, and it really depends on, what the thing is I'm refactoring. I have, number 1, always make a branch.

Start with number 1. Make sure you commit all of your code currently and make a branch. Because if you start tweaking stuff and all of a sudden it breaks and they are in your main branch and you have some code changes you didn't commit beforehand, you're gonna be frustrated that you are now having this project that's not working.

Also, you want something that you can just go back to if you goof it up.

So I have a couple of strategies. It depends on if I'm if I'm refactoring a beast of a file. I'm gonna branch. I'm gonna duplicate that beast of a file, and then I'm just gonna go hard deleting stuff, completely rewriting it. Right? And, then just largely, that one is going to be probably a Deno investment before you see anything working again.

The other way to take this would be to change small parts surgically, and this one works best if you have tests. If you have good tests that say, this is how this thing works, and you don't wanna have to rewrite your Wes. You just wanna say, okay. This thing should function the exact same way it did before. If you're using React testing library with data IDs, that shouldn't be too much of a problem.

If you have that sort of setup going, then just surgically change out those things, rewrite them, move them, whatever, being careful not to break your tests.

The last way I have is to migrate the things that are easy to migrate before rewriting a bunch of code. Let's say your refactor is you're taking this thing from a class component and you're moving it to a function based component. Now I know the React team says don't do this, but I have components that would be so much more elegant in a hooks based setup, and I have hooks to help me. So maybe I think, okay. Well, this would be better with my own custom hooks. They'd be better with my setup. They'd be better as a function component. Let's go ahead and rewrite this thing.

If I'm using component did mount, component will mount. Though, if I'm using those life cycle hooks, what I'm going to do is I'm going to use actual React hooks that mimic that functionality first and foremost.

Why? Well, because it's important to get this thing up and running as a function component if you're doing that sort of transition.

It's important to get it up and running and then think about how you can restructure it. Because if you are refactoring your your component, maybe you you swap out alright. I did the class for a function component. Now I can take a look at these maybe non optimal hooks like an unmount hook or something that you have. I can take a look at that and then think about how this could be written with the use effect properly rather than, doing it all at once. Do it 1 step at a time. So there's some different approaches, but the main thing is have tests, branch, and commit often, and don't be afraid to really go radical with some things.

Yeah. My tip for, like, if you have, like, a ugly piece of code that just does too much is take a look at it. Obviously, if you have Wes, great. Maybe that's not always the case, but just go and take that huge take that thing that bugs you the most and make sure it's working and then just go through piece by piece and say, like, what can I make into a smaller function? How can I chop this out into to other pieces? Can I put them in their own file or or something like that? And just by sort of, like, going file by file, trying to clean it up and and tight tidy it up, often then you'll start to see, I'm doing the same thing over a few times. Like, I just wrote for the footer of my own website. I wrote this thing that would fetch my in latest Instagrams, and then I wrote another thing that would fetch my Instagram stories, and then I wrote another one that would fetch my Twitter feed.

And I was like, man, this is mostly the same. Mostly just going to an API, fetching data, and returning it back. And that's the point where I'm sitting now, and I say, okay. I could probably refactor this out into Mhmm. A smaller reusable hook or whatever it is that I'm using. You know what? You're not going to like this.

And then but, the the the the thing that gives me the most amount of confidence when refactoring my components right now Yeah. Is TypeScript.

And the reason I think would I not like that? Because TypeScript people are lying TypeScript, TypeScript, TypeScript all the time. Oh, okay. I need to let's let's make this clear. I'm not anti TypeScript.

TypeScript. I get that. Yeah. No. But people on Twitter keep saying, like, why do you hate TypeScript? I use TypeScript.

I just don't have a huge project in it right Node.

So, like, don't pay me as the anti TypeScript guy. I'm I'm not trying to pay you as that. Okay. The reason I say that is only because it's like TypeScript people often say that, like, TypeScript is the solution to, like, every single problem. Oh, yeah. And and that can get really annoying really quickly. So not to say that you specifically don't like TypeScript, but just to not I don't wanna be that guy because now that I it's like 2 months ago Wes I didn't have my entire application written in TypeScript, I was in your same boat. I've used it on projects. I was just, you know, whatever.

It exists, and it's cool. And now I'm, like, slowly turning into one of those

annoying TypeScript people that's like, boom. So but the the ref refactoring, even, like, renaming a function across multiple files, that that refactor is such a snap in TypeScript versus Mhmm. The Versus Code does a okay job at it, but, like, so much easier in TypeScript if if you have all of that stuff properly set up. I like it just for my components

complaining now. It's like, oh, I don't have the props that I should have, or I am being passed something that I shouldn't have. And it's, like, may really made all my stuff more organized. Okay. Off the soapbox. And, while I get off my soapbox, maybe I'm going to sell this soapbox full of soap on Etsy right Node, but for some side income. And then if I do that, I'm gonna need to track it on FreshBooks.

Right? That's pretty good.

Yes.

That was okay. It was okay. Yes.

FreshBooks JS, the small business accounting software that makes your billing painless. So if you are running an Etsy shop selling soap or if you are a web developer trying to keep track of your expenses and, money coming in, see who's paid you, whatnot, sign up for FreshBooks and get all of that cloud accounting in one spot. Go to freshbooks.comforward / syntax and use syntax in the how did you hear about us section that is gonna give you a 30 day unrestricted free trial. Thanks so much to FreshBooks for sponsoring.

Awesome.

So next question from Creso.

Which technology stack would you choose for 2020 ecommerce and why? Okay. Ecommerce 2020.

Yeah. Yeah. So okay. It really depends on who your client is. Right? If your client is somebody who's nontechnical, Shopify all the way, best experience, most templates, biggest community. There's a 1,000 Shopify developers.

So if they need work done, they'll be able to find somebody really quickly. So I think Shopify is sort of the winner for the easiest overall if you're just building in their platform. If you wanna get something a little bit more, I don't know, developer y, a little bit more hipstery, you can use Shopify as a back end for a Gatsby site or even a Next. Js site. And the Shopify API, it takes some getting used to, but all in all, JS pretty dang good. And they have some iframe cart stuff, so you don't have to, like, build your own shopping cart. You can just drop in their Iframe cart, and then you can have your whole Gatsby site the way it is. So it's pretty cool, but it doesn't really give you a ton of ton of options in terms of, like, giving the client those pages that they might be used to to see their orders and things. You're gonna have to dive in a little bit more. If you want to go for a really cool little option here, there's a, platform called Snipkart.

It's funny because they sponsored us a little while ago. So I don't this is they sponsored us a long time ago. This is not, a paid promotion in any sort of way. But Snipkart is sort of what I was talking about, like, when you have the iframing in with the Shopify and Gatsby thing. What it does is it basically is a ecommerce platform built for Jamstack specifically, and its intention is to be a seamless experience on top of your site.

And I believe it's all iframed in. I'm not entirely positive.

It looks really, really nice. I have not used it on any projects, but it looks really super interesting, and I'm keeping an eye on as something that I would use if I was going to be building an e commerce site. But Shopify, Snipcarts, I would probably stay away from Magento, but only because of my own personal experiences in Magento one, which Yeah. Is so funny. I one of them. Them I have, like, 70 tutorials on Magento Node on YouTube, and people are always like, why don't you do Magento tutorials still? It's just like, because I really didn't like it before, and I don't like it now. I just did it because I was working in Magento every single day, so I knew it pretty well at the time.

Adobe bought Magento? Yeah. A few years ago.

Yeah. Right after Magento 2 came out. And Magento 2 was sort of this, in my mind, botched launch. I have no idea what the status of Magento 2 is right Node, but it seemed like when they first launched Magento 2, it was I don't know. So, like, my my my experience in Magento JS I have this, like, really weird relationship with Magento where it was the very first platform I ever built a site with a database, a MySQL database, and a, like, PHP. So, like, most people cut their teeth on WordPress in that regard, but, like, Magento was it for me. Like, my first experience with PHP and databases was Magento. So I have this, like, very tight fondness for it, and at the same regard, I absolutely despise it. So

it's it's a tough balance. That's a funny thing that happens is that, I think I think this is partly why WordPress gets a bad rap as well. It's because it is the first thing that people did, and they wrote some awful code and did some terrible things and weren't totally sure what was going on. And that's not to say that that WordPress doesn't have its own fault, but it's funny when you look back at your the first thing that you ever did, most people don't look back at it fondly.

Yeah. And so if you're a Magento developer and I'm totally wrong about this, don't be don't be too mad. I haven't really looked at this in too long. It it it could be just fine. I see that they have a GraphQL API and whatever, but I've just never been a I've never been a big fan. So Yeah. I I just made

you know those triangles where you're allowed to pick 2? Yeah. Yes. Yeah. So I think online ecommerce has a triangle where you have easy, control, and cheap. Yes. You gotta pick 2. You gotta pick 2. So Yeah. You don't get them. It Sanity be easy and cheap, but you don't get full control over over everything you want. It can be easy and you can have control, and and I think that's that's what Shopify is. It's easy and you can have a lot of control, but you're you're gonna pay through the nose, on add ons and things like that. And then if you want control and cheap, that's building it yourself, and that's not gonna be easy. You you can certainly, do it. Like, I run my own, and I just have digital products with no shipping and no inventory, and it's hard enough.

Ecommerce, man. I can't even imagine doing, like, a real wet a real store that has products and shipping and, order tracking and different SKUs, different sizes, things like that. It certainly would have to go, off the shelf for something like that. Yeah. Totally.

Next question we have here is from Luke.

I'm confused about, developing a website for a client. I feel like most, if not all, clients want to take administrative control at the end of the product and be able to handle things themselves. Does this mean I the only option for client projects is WordPress? I got really excited about making ESLint site in Gatsby, but they would need to be a coder to be able to edit the content of the site or maintain it. Am I missing something here? Well, where's our Sanity sponsorship today? Yeah. Right. The thing that you're missing is is that WordPress is a CMS, and the thing that people like about WordPress is the fact that it has a really nice back end that clients like, and they've got lots of control, lots of plug ins, and things like that. And then the other end of it is is where the data comes out, and then that's where you, the developer, go in and go in and start to pull the content and and display it on a website. So the thing you're missing here is that Gatsby is more just the theme or it JS just the theme. It's it's how you, data and template it out.

Where the data lives and how that data is controlled is up to your CMS. So, whether that's WordPress, and you can use the the headless part of WordPress for that with Gatsby if you like or, whether that's Sanity or, any one of these other, headless CMSs that we you can go and listen to the entire headless CMS podcast that we did, and we listed out about 10 of the different ones out there.

So that I think that's the part that you're missing.

Being able to control what the site looks like.

Like, generally sorry. I should let me back that up. Generally, you're not coding content directly into a Gatsby page unless you are actually a developer like I am.

And I say that because my Gatsby website has paragraph tags coded right into the pages, where in most cases, you're gonna stick that in some sort of CMS.

I like how you said that get like, the Gatsby Node is just the theme. I think too often, we forget that it is basically just like the theme template. And why would you use that over a WordPress theme template? Well, you get easy react. You get that prefetching. You get that image transition. You get some really insane speeds overall. I mean, just Gatsby sites are fantastic experiences, so that's why you would use it. But at the end of the day, like you said, it is just the theme. You need a back end. You typically are going to be connecting data to it in some sort of way unless, of course, you are a developer editing those templates yourself. So if a client needs to use it, yeah, you need to have some sort of a back end in there. And don't make that back up back in GitHub. Your clients don't want to edit GitHub. That's what I have to continually tell people that.

I know. People are like, oh, why did why are you using GitHub? Why using MDX and whatever? Like, that's not real. And I was like, I know it's not. Like, don't ever give your client a markdown file on GitHub. That's not a Yeah. They don't want For me, it is because I'm a developer, and I want to be able to put my stuff on GitHub. But for most people, no. You shouldn't do that.

Right. I know. And and yeah. It's not about babying your clients or whatever. It's about providing them with a good experience and being a good developer. Alright. Next question is for Dan, the context man.

I'm assuming this is the same Dan the man as the other Dan the man, but Dan asked some good questions here. How do I use prop types and type check a component when getting the props from context instead of passing them down.

So how do I use prop types to check? The big thing here is that your provider is still a component. Right? In fact, I always make a provider component where it's like a function that has the whatever context dot provider.

In there, I would have my prop types in. I guess those aren't coming in as props, though.

You know what? This is an interesting question and one that I haven't had to think about beyond the fact that if you use TypeScript, it actually is much better because when you have props coming into component, you have to type them in every single time, and it gets totally redone with all of the types you have to write. Where with, context, you can write your TypeScript types within that context, and it's going to just pass those into the component as their type rather than having you to redefine the type JS what it's like coming in on every single time.

So I guess the problem with this question is is I initially read it as how do you type check? And I was thinking, oh, TypeScript makes it super easy. And now that I'm thinking about it, how do you use prop types in this way? I'm not quite sure. And I think that is maybe part of the problem with prop types overall. Prop types, to me, never felt as secure of a solution as TypeScript types, and I did use prop types extensively.

So I don't know if I have a great answer for this. If you do have a good answer, what's the best way to type context with prop types here? Let me know. We'll retweet you on the show notes. I think this is an interesting question, one that is, solved by TypeScript.

Awesome. Yeah. I I don't totally understand this question, so I will pass on it.

Next question we have here is from David.

Should I use the MongoDB or Mongoose Node module in my project? Are the differences?

I don't know. I've only ever used Mongoose myself. That's the way I learned it. That's the way I like it. I'll tell you. What is it, Scott? The difference is is that Mongo doesn't include any of the validation or schema stuff. So you use you would have to build bring in a third party package. Like, we used to use on level of tutorials. We used to use Mongo, and, we did it with a, schema package called simple schema, which was great for a long time, but we eventually moved to Mongoose because it offered more features, essentially.

So which should you use? Whichever you like, if you want something that includes validation, then use Mongoose. If you wanna write your own validations and you wanna write your own stuff there, you want a little bit more flexibility and a little bit more freedom, then choose Mongo.

Mongoose is a very widely used package and highly supported, so I don't think it's gonna be at risk of going away anytime soon, Node think. So I personally use Mongoose now. Yeah. I I saw a,

a Reddit thread, unpopular web dev opinions.

And the most popular one was MongoDB and Mongoose is not used in the real world, and it's just a tutorial language. And everybody's like, yeah. Thank you. And I was like, What? No.

No. Yeah. No. Successful business over here on on Mongoose and and MongoDB, and I I think that it gets a bit of a I think the same thing happens with Firebase. Because it's so easy to get up and running Yeah. It's pretty popular to be used in tutorials, and then people think of it as a toy and not a real world thing. But, certainly, there are like, MongoDB is a publicly traded company. Are they not? They are a very profitable,

company.

They have m MDB. So they're a publicly traded company.

In my mind, MongoDB, the company, is very much like, Red Hat or IBM or Oracle or, like, a big company like that because they are a company that has open source software, but also, like, is a publicly traded company making money off of that.

So, generally, publicly traded companies don't just they're they're not made from tutorial companies, except Pluralsight is publicly traded, though.

Yeah. Right? Oh. Yeah. But yeah. So it it that wasn't really the question, but, I don't think it's just a toy toy, there. It certainly does have downsides compared to other languages or other databases, but, it JS a good database.

It's a good database. Database. It's a good pup. It's it's a good Wait. What's that meme? Yeah.

They're good they're good dogs, Kent.

I don't know that, but it sounds cool. Good. I like dogs.

They're good dogs, Brent.

It's a good database, Brent. You don't know that meme? It's a good database. They're good I don't know that meme. I I I would consider I would I'm pretty memed up too. I I mean, I know the memes. I'm I'm with the memes.

Alright. Let's do a little meme explainer right here. So yeah. So there's this Twitter account, called dog_ rates, and he always rates them, like, 11 out of 10. Great dog. Like, everything is amazing, and there's no bad dogs.

And some guy named Brandt says, your rating system sucks. You just changed your name to cute dogs, And he replies, you give every dog elevens and twelves. It doesn't make any sense. So he replies, Brent. They're good dogs, Brent.

They're good databases.

It's just good database.

It's all good.

Mixed stuff.

Yeah. No. I mean, all this stuff is whatever you're proficient in, you know, can be effective, and, certainly, you can scale to have a very profitable business with MongoDB.

So next question here is from Adrian. This is the last question here. We have a hefty, hefty potluck for you here today.

So last question from Adrian. He says, is it bad practice if I mix up React Bootstrap and Material UI in Node React project. Yes.

Yes. It's a bad practice.

And, let me tell you why it's a bad practice. Besides the fact that both of those libraries have very specific, you know, UI ways of doing things that are very specific to their design system. So if you mix 1 with the other, what you're gonna get is a Frankenstein looking thing. You're gonna have, you know, an arm sticking out of your website and the legs sticking out over here. You're gonna have some bolts in the neck of it, and it's gonna probably stand up and move around fine, but it's going to be Frankenstein together. You don't wanna do that. Number 2, part 2. Here's the here's the big big meat of this. Here's the big meat. The big meat is, one big old kielbasa.

It is too too large in in size. Right? You're adding so much additional bloat via CSS, JavaScript, whatever, especially if these are React Bootstrap, React Material UI. You are adding major KBs major KB toys to your site here, and, we don't wanna do that wherever you can. In fact, this is one of the reasons why I don't use frameworks at all because, honestly, they usually add a little bit of extra bulk to your project that it might not need. So if you are using one of them, stick with 1 of them. You can do every single thing you could possibly need to do in one of them by using it or extending it. There is absolutely no reason to use both of them.

Alright.

I have nothing to add to it. Scott nailed that there. Let's move on to some sick picks.

I am going to sick pick, new Netflix series that everybody has been watching called Tiger King. Have you have you seen this yet, Scott?

Yeah. And it's funny. I I listened to a podcast that covered Node Exotic before Wondery did a podcast, before this whole thing went down, before any of this stuff happened. They were, like, covering him as being like, alright. This crazy guy did something crazy again. And so I had him I knew about him, and then I listened to the Wondery podcast. So by the time that the Tiger King came out, I knew the whole story. Wow. Courtney didn't know any of it. And we watched, I think, the first like, all of the episodes but 1, and Courtney was like, I'm I can't watch this anymore. I know I can't all the animal abuse. So we have not finished it, but we watched it. And I I mean, I thought it was I knew the story, so, like, the story wasn't riveting to me, but the production was certainly great. And, seeing some things like Carole Baskin's husband wearing the tiger collar at their wedding thing, like, that was pretty shocking.

So Unfortunately, I was the most shocking thing in the entire thing.

What I was gonna say is, I think the back channels is just as interesting as the actual thing itself.

Like, this podcast you talked about, I'm gonna go listen to that.

David Spade has a YouTube channel where he interviews every single person. He's, like, the Oprah of Tiger King. Jeez. And, I didn't know that. Yeah. Super interesting to hear, like, people's like, they're able to finally, like, talk after it's all come out, and they're able to give their own thoughts as to to what happened and very interesting. So check it out, Tiger King as well as back channels.

I'm sure there will be a lot more. I'm sure there will be an entire podcast that's just dedicated to to this Netflix series.

Yeah. Well, the Wondery one does a good job because it's, I think, it's a little bit longer, and it's Wondery. They're the ones who did Dirty John and all those. So they they're, like, very tuned at this style of podcast. They're like you know, it's funny because, like, podcasts are this this whole medium, and there's this, like, type of podcast that is seen as maybe almost like the HBO of podcast, right, where it's, like, always going to be high quality stuff. Yeah. You know when they put it out, but it might not be for you. And it's so funny that I've, like, gone back and listened to some of these, like, must listen to podcasts, like Up and Vanished and some of these other ones that are, like, essential podcasts in the genre. And I, like, walk away always being like, yeah. That was really good. Like, they did a good job on that. And and, you know, I put off a lot of stuff like that. So, Wondery One, check it out. It's really good.

My sick pick is going to be, murder murder party 2 on the Jackbox 6, Jackbox Sanity Pack. This is one of those things that you can now buy online and play over Zoom. We've been doing that, I mentioned, in the last show because we own it on Switch. So I used my Cam Link to hook up the Switch and stream my Switch over Zoom, which is pretty sweet. I'd never now I feel like I could be a game streamer. Here's me playing, Animal Crossing as I'm, currently speaking of yeah. Yeah. I'm doing I'm doing that right now. I'm building a large fenced and private beach, and none of my residents can use the beach but me. So, no. I I'm gonna start I'm gonna start doing that either way. Okay. Getting off topic here. Jackbox Sanity Pack, you can play it online now if you buy it over Steam. It's really super cool. It's a game you play with your phones. I specifically am recommending the Murder Party 2. It is just a quiz game, a bunch of fun questions. My whole family has been drinking gratuitously and playing it online. It's been a lot of fun.

Awesome.

Shameless plugs. I'm gonna shamelessly plug my beginner JavaScript course at beginner javascript.com.

If you want to brush up or slam dunk the fundamentals or you're brand new to JavaScript, this is a course to take. We use coupon code syntax for $10 off Beginner JavaScript Scott.

Cool. I am going to plug my latest course, which is called custom React Hooks. And the custom React Hooks is a really cool course because what we do is we talk a little bit about the process of writing your own custom hooks. Throughout the course, we're constantly writing custom hooks. So we I don't know how many it is. We may be right, you know, 15 different custom React hooks over the course of the video, but we talk a little bit about when, where, why, how, what you do to write them, why you would use certain techniques, when to use certain other techniques, commonly used patterns that you'll see in other people's custom hooks. It's really stinking cool. And it's actually on sale for 50% off right now. That's not something I typically do, but with the current situation, it is 50% off. And if you use the coupon code syntax, you'll get an additional 10% off. So it's basically free. So head on over to leveluptutorials.com, and I'll have the link in the description. You can either sign up to become a pro subscriber and get access to all that and more or buy this course outright, a la carte.

Beautiful. Alright. Thanks for tuning in to the potluck, and we will catch you on Monday.

Later. Peace.

Peace.

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