Potluck - Bootcamps × Career Change × Figma × Gatsby × AMP × Mongoose × More!

and Wes Bos. Welcome to Syntax. Today, we've got me and Scott pulling up to the table, and we're ready to feast on some questions. Wes if you've never listened to before, the is where we answer your questions. You can submit your own questions at syntax.fm.

In the top right hand corner, there is a button. Click it. It says ask a potluck question. That brings you to a very generic, ugly Google form where you can type in your question. And, let me say, like, last potluck, we had some banger questions. This one, really good questions.

I feel like the questions have been getting really, really good. Don't you, Scott? Super good. Loving them. Loving them. That's great. So today, we are sponsored by 2 awesome companies. First1, Scott tech domains, which is going to get you literally a .tech domain, and the other one is LogRocket, which is all your client side session replay that you need. We'll talk about them partway through the episode.

How are you doing today, mister Tolinski?

Woo Bos. I'm doing good. I am I'm working on some stuff. I'm trying to, move some of my video streaming over to Cloudflare's video streaming platform. Yeah. And it's pretty darn neat. I've built this neat little system for importing it, sort of like what I have with my YouTube one. It's like a one click importer to import all the videos in a specific series. It's becoming a lot of fun, and, I'm gonna maybe live stream a little bit today. So, obviously, you're not listening to this while we're talking, so you can't tune in. But you may be watching after the fact if you're interested on some of this Cloudflare streaming stuff I'm working on. That's some of my favorite coding is

scripting things Scripting. Where you autumn like, I just recently

have been importing all of my hot tips from Twitter and all of my blog posts into MDX on for my blog. And I had to write these gnarly, huge scripts to to do it, And I have a lot of fun doing it. I don't know what it is about writing all this code to automate all the steps to that, but some of my favorite. There's something just very gratifying about being able to take things like that into your own hands and just do it. You Node? It's like, here's a system that works in a specific way. It would be really cool if I could manipulate it this way and then one one click, get this going and this going and this going, and the next thing you know, you've got yourself some really fancy stuff working. I'm a huge fan of of this kind of coding too. It makes you feel very productive.

Yeah. Yeah. It does. And very, very powerful as well because, certainly you see people in other jobs that say, oh, I spent my entire day moving over from 1 CMS to another or copy pasting this or or searching them. Like, I probably could have scripted that in the same amount of time, but Yeah. Right. I would have scripted it. It would have been way more fun than copy pasting. Yeah. You could've learned something too.

Let's, jump into the first question. You wanna grab it there?

Yeah. So this question is from Eric, and this question is, hey, Scott.

You talk a lot about your workflow with Figma.

As a designer going to programming, it sounds like the workflow Wes natural for you. As a programmer, I tried to move into design. I have no idea how to get started. Could you explain your workflow in starting a new project in Figma and starting an implementation of Versus Node? I've been listening a long time. I appreciate the positivity of this show and the it's our show. We'll do what we want attitude. It is our show. We do what we want here. It's our show. Want. Yeah. If we wanna make some cringey comments about tasty treats and stuffing your mouth and whatever, then Mhmm. We're gonna do it.

If we wanna have a 45 minute hasty treat on Monday, we'll do it. We'll do it. Who cares? It's not very hasty, but who cares? No. Tasty. Tasty. Okay. So this, this this question JS interesting because I wouldn't necessarily say I'm adept at this or I'm great at this or anything, but I did recently redesign the entirety of level of tutorials, and I did so starting from scratch scratch.

So if you're not starting from scratch scratch, I would recommend grabbing a starter kit. Now there's starter kits all over the Internet, depending on which application you're using. If you're using, let's say, Figma or Sketch or Framer or whatever, you could just Google blank starter kit, and you'll find things. And oftentimes, you'll see those as, like, kitchen sink sort of systems or or ones where they have basically every component. And those are nice to start off on. But in me, personally, I prefer to start with a blank slate. And, typically, when you know when you're building an application, you know the stuff that you're going to Node. You're going to need text pnpm.

You're going to need cards, maybe headers. You're going to need paragraphs.

And I just start making a frame full of each of the groupings, a frame for buttons, a frame for form components, a frame for links, a frame for type systems. And I just start grinding it out, turning those into components. And then in my actual designs, using those components as sort of Lego pieces to assemble the designs and doing so just a component first basis. Right? Everything's all about those component components.

And so if you start to look at design while your designing has not only HTML elements, right, the stuff that you need, but also React components. Here's a card. What can a card entail? What can it have? What can it do? If you have the programming background already, just start thinking of it the exact same way you would assembling a React component, and that should help you start to assemble those things within your design system.

Awesome.

Next question we have here is from Burhan.

Think that's it? Burhan from Stockholm.

Burhan. Burhan. He's got an umlaut. The dreaded monitor Wes,

flat or curved? Oh, I'll let you, you start with this one, Scott. Flat or curved? I got a a curved 38 inches all day, man.

This is man. It expands across your whole view. It the curved is amazing. It's amazing for a lot of things. And to be honest, like, some people will say, like, I want a flat monitor because I don't want the curve affecting how I view things. I don't think that really matters as your periphery view goes. If this thing's in front of me, the curve helps so much. It's a very slight curve, but it's a it's a decent curve, and it's fantastic.

The curve sounds amazing. I have 2 4 k's, 132 inch and Wes inch, which I run on sideways.

And the only reason I don't go curved because I I definitely think curved is is better JS just because I want more of the vertical resolution.

Yeah. And I want 4 k, like, high density pixel versus just regular 10 80.

So they are working on them. They have a couple out so far, but they're, like, more than my house cost. Yeah. But once there is a 38 inch 4 k monitor that goes more than 14 40 pixels high, that seems to be the limit right now on the height of the resolution, I'll be all over it just because, like, I've I quite honestly, it's it's almost too much too wide for me right now with all the the different monitors that I have right now. It's so good for video editing. Like, have that whole timeline span, that whole thing, so much visibility.

Yeah. Oh, yeah. And for when render props warp a thing, you could view all of your code at once.

Or Hayley nested CSS. That's a good one. Yeah.

Yeah. You could if you could view all of your sass. I once had a student at a boot camp, and this is not making fun of them. Just I thought it was it was a JS a little bit funny because we taught them, like, nesting and CSS. So they they nested everything. They started with body and went all the way down. I think everybody has over nested at some point in their career. Yeah. We've all been there. Maybe not to that degree, but to to some degree.

There's, like, some sort of, like, curve of, like, when you start CSS and you learn about ESLint, and it goes right up, and then you get better at CSS and you realize,

oh, what is the rule? Never more than 2 or it's never more than 3? I don't know. I never even think about it now because I just think about scoping and containment rather than, like, how deep I am nested.

Yeah. The scoping gets rid of a lot of the nesting anyway.

Totally. So I I love talking about monitors. I've I'm on this 32 inch, which I think is the developer monitor right now, but that might change.

Yeah. Yeah. Big fan of the widescreen. Alright. This next question, actually but they that they wanted you to try to butcher their Node. So, I'm gonna give you the chance to do that before I read the question.

Alright. Okay. So it's spelled t s I o l I Wes, and I think it's Ciolis?

Ciolis sounds fine to me. I didn't butcher it.

I think you did a pretty good job. Alright. This question is Can I butcher it?

To to Solios.

To Solios.

Okay.

So, this question says it's for me, but I think you have a good perspective on this as well. It says, question for Scott. I'm relatively due to web development and have learned HTML, CSS, Node, and Mongo. I'm planning on taking your, as in my, Gatsby e commerce course. However, I have Node experience in React.

Should I learn React first? So the basics of this question, if you boil it down, is I want to learn Gatsby, specifically Gatsby in e commerce. I'm actually wearing a Gatsby t shirt right now. Should you learn React first or React with Gatsby? Now I would say learn React first and learn it.

You're gonna wanna learn it decently well. You could pick up Gatsby, and you could build a basic site just with your HTML JavaScript skills. But the moment you need to do anything, you're probably gonna start making bad choices right away because you don't understand the foundation. So I would say spend some decent amount of time learning React foundations. You don't Scott be React Masterman or anything like that, but, spend some decent time just really hammering out the basics.

Yeah. I think that I I I've had this question before because I have a Gatsby workshop, and people email me and say, hey. Like like, how much of React do I need to know? Mhmm. And my answer to that is very little because you need to know templating and components and props.

But if I think about even my own website that I'm working on, the amount of custom React hooks that I have in there is very minimal.

And for for ecommerce, it's probably different because you do need to listen for clicks and and fire off things and show loading states and whatnot. But for a lot of Gatsby websites that are just websites that don't do anything, they just display content, you can get away. If anything, I look at my own personal website I'm building on Gatsby. It's way more custom node work than it is actual custom React.

Yeah. Yeah. It's GraphQL.

It's Node. It's Node APIs. It's writing to file system Wes, all that stuff. Mhmm. So, yeah, I I think you should know a little bit enough to template out. And then as soon as you get into that, like, situation, you go, I need to I fetch some data on the client side, or I need to listen for a click, or I need to take this data from the nav of, like, what page we're on and and bring that much lower somewhere else. And I need to put that in context, then you need to get into React, but, not a whole lot. And, I think Gatsby can also be a bit of a gateway drug to React.

Yeah. I agree. And, I mean, I I still think you should probably learn those React foundations and fundamentals. But, I I mean, I totally agree that without knowing them, you can accomplish an insane amount within Gatsby, and I think that's a testament to just how excellent Scott only React is, but, like, the power of of Gatsby. Some people will say, like, why would you ever use React for a static site, or why would you go why is that overkill? But if you actually look at the code, the HTML that you're writing or the JSX, you should say, with the React and Gatsby code, it's really simple, and it's really just basically HTML anyways.

So if it's spitting out a static site and you have some HTML and you're not doing anything crazy, why wouldn't you use something like Gatsby, which isn't really gonna give you that much overhead into your site anyway? So, I'm a huge fan of of just using Gatsby in general. But, yeah, yeah, there there are definitely React specific things and Gatsby specific things that you may hit along the way.

Thank you, Tysenolius.

That was a great question.

Next question we have here is from Mark Foster. Hello, Mark Foster.

I'm assuming I was never a good Australian.

And should I be using it? So AMP is Google's proprietary.

No.

There's a lot of, like, heat around what AMP heat. I know. I see I could see you dancing around that heat just now. But, basically, what it is is, Google rolled out this thing called AMP, and you can make AMP versions of your website that are very stripped down.

They've compressed images. They've got just HTML. Not a lot of custom JavaScript is running on it. And the upside to that is that they load very fast.

Google caches them on their own server, and they often will preload them. So by the time you tap the link, it's just, boop, immediately you're seeing the website, which is good. As a user of AMP websites, I often say, this is better than having the 5,000 injecting ads, autoplaying video.

All this like, especially now, like, I don't I don't read a lot of news. But with this coronavirus going along, I've been, like, going to random websites that people have been posting on Twitter, and I'm just like, this is awful to experience all these cookie pop ups and slide downs and email sign ups. I'm like, this this is awful that we've done this to the the web. And they don't even give you real cookies.

They there you go.

If you're gonna get a cookie pop up, you gotta get some cookies out of it, man. There you go. That's that's pretty good.

So why do why shouldn't you be using app? Well, Google invented it, and there's some ideas that they give those websites precedence in search results over others. Whether that's true or not is still out to be seen. And it's also it's not very, like, standards friendly because, like, doesn't HTML already do this? We just sort of goofed it up by putting in so much extra JavaScript and images and and tracking and things like that.

So, personally, I've never gone down the AMP world, but I know people who work for big publications probably couldn't live without it in terms of traffic. What do you think?

Yeah. It is such a slippery road because there are just fiery there's fiery opinions on this Node, and I I it depends on on on what the audience is, who your audience is, and if they require it. If your boss is saying Wes need AMP because, you know, it's it's faster than every other news company has, then, yeah, implement AMP. But, again, the whole proprietariness of it and the sort of weird it's a it's a turn off for me in terms of using and implementing it myself. I'm not I'm not rushing to implement it in my platform, so to Sanity. But, of course, my platform is not the New York Times or something. You know? So I I guess it's

it's industry specific in my mind in terms of what you're trying to support and who you need to support and what your competitors are doing and all those things. But Mhmm. It's a it's a tough tough road to And, also, Facebook has its own version called Facebook ESLint Articles. Scott doing that. And you're actually technically don't get the users on your website either. They're on, like, the URL. And like, I see it all the time where people that are not technical share the URL and it's like Google AMP content Scott Yeah. Whatever.com.

And I'm just like, like, you're you're breaking the Internet here. Right. And I hate that. I hate it so much that I just don't wanna like, you wanna rebel against that kind of thing and say, I'm not gonna do that. But at the end of the day, you Node always get to make those decisions. At least idea. So yeah. So next question is from a Christian. Christian asks, what are the advantages and disadvantages of building in a web app using a framework such as Blitz Blitz dot JS? Now we get a lot of these questions that are like, what do you think about this framework? And then all the time, we're like, I've never heard of that framework. What was that? I feel like there's one fairly recently that I had never heard of. So, this Node, I have not heard of Blitz until this question came in. So thank you, Christian.

I, am now aware of Blitz. It says it's a framework for building monolithic full stack serverless wait. Monolithic? Serverless? I feel like those are conflicting ideas.

Monolithic, full stack Probably tongue in cheek that it it probably can do both of those. Serverless React apps with 0 data fetching and 0 client side state management.

Wait. What? Node data fetching and 0 client side state management.

So what is this?

Is this real? I I have I'm having a lot of Yeah. I'm so I'm just looking at it here. I went to the author's Twitter page, who, by the way, has the most cool Twitter photo ever. So go to his thing, twitter.comforward/flybear.

He's got a dually truck in this massive RV with, like, triple axle RV with the American flag and a eagle pulling it, that's the most bad, cool thing I've ever I'm not gonna say a s s because there's kids that listen to this, but, it's the most cool thing I've ever seen. You need to see this, Scott.

Oh my gosh. This is I'm not even American, and I feel patriotic seeing that.

So this is all just okay. So it's it's basically what I'm gathering here. 0 client side data fetching or state management. All data reads and writes happen server side.

So it looks like rail style routing rails style, REPL, REST GraphQL API, optional, but not required. Both a c okay. So this is absolutely real. I was just, I don't know why I was, like, reading this thing JS it's it's so funny because their their Twitter announcement about it tells more about what it is and what it does than the website does.

So it'd be cool if the website maybe had some of that information on it.

No. I've never heard of this.

Would I, advantages and disadvantages? I don't know if I can necessarily say. It seems like this is wanting to be some sort of, like, a a full stack Rails thing. I personally use a a framework called Meteor, which, you know, is a full stack sort of thing Wes I get access to the database and node and all those things directly in my application.

So I'm by no means against a full stack framework, by no means against it. In fact, I really like using full stack frameworks whenever, I can JS long as they're, good and work well. This one looks interesting. At a first glance, I wasn't quite sure about it, but now a little bit more work. I don't know. I think they need more

examples. I mean, I think I think I need to see more more about this. Yeah. It's a hard thing when you come out with this, a new framework to clearly communicate what it is and why someone might need that.

So I'm definitely gonna need to take a little bit more longer look at the Blitz. Wes, but definitely pretty cool.

I love seeing people put out new frameworks.

If you've used Blitz. Js, which it looks like this tweet is just from February 17th, so this is very fresh.

If you've used this or tried this or anything by now, please let us know. I'm interested to hear what your experiences around Blitz JS are or if you are just overwhelmed that there's another option, which you shouldn't be, then just don't tell us at all because I don't want you Oh, you know what? I wonder if this

I'm just looking at some example code that's posted, and there's, like, database, queries, like, right in the React component.

I think how this works is that it probably it obviously renders it all server side. But since it's React, it probably just streams the changes to the Dom.

So you're not actually running React on the client side, but it's just streaming the Dom diffs to the to the client. Doesn't Netflix do something like that? Like, Netflix doesn't use any client side reactor? Am I tripping? There was a demo with, what is it called? What's the new thing coming out in React? Name of my suspense. That will never come out. Suspense.

So there was a demo with suspense where it was just running React client side, and then it was just using a WebSocket to stream the changes to the client side, which is pretty nifty. So then on the client side, you just have, like, a couple of lines of JavaScript that just dump the HTML into the correlated div and you're off and running. So I bet that's what something like this does. And and that if that's the case where it's all server side, you don't have to worry about, like, auth or anything like that on the client side, which is pretty nifty.

Yeah. This is is actually fascinating that it's a full stack

monolith. So you're writing everything in 1 spot, but what it deploys, serverless functions. We're gonna have to take a more look at this. I I did not hear about this, but I'm gonna I'm gonna take a a little dive into this after the show. So Cool. Well, I I love seeing new new frameworks like this come out because these these are the types of things where it might not take off. It might just have its own little thing, but that that's also how view started. Right? And then Node totally shook up the whole industry. So big fan of so when stuff like that happens.

Cool.

Next question we have here is from Christopher Talk.

Would you ever consider moving from mongo Mongo slash Mongoose? So I I'm assuming he means, like, the database that we use. Both of us use MongoDB on our apps. Both of us use Mongoose, which is a node package for interfacing with MongoDB.

Would I ever consider moving from it in a new project? Absolutely. Every new project that I have, I I reconsider what database I should be using. I use DynamoDB in a little toy project the other day, which is really fun.

Dynamo.

Dynamo. That's like the Amazon Web Services.

I know. Isn't it Dynamo?

Node dynam die yeah. You're probably right. Dynamo. Dynamo.

Why do I Dynamo?

Dynamo.

I don't know. Yeah.

Dynamo.

I'm just resting here. I don't know if you know. You know why it is? It's because in, Canada, we have this little treat called the Nanaimo bar. You ever had a Nanaimo bar? I haven't.

I have not had a Nanaimo. I was thinking it was like a dynamo bar.

So I would. Would I ever move my own platform over? No way. I don't have zero problems with MongoDB.

There's no way I wanna rewrite all of my code for 0 benefit.

Big fan of how MongoDB works.

So, no, not on my own application, but other applications. I'm I'm constantly looking at different databases.

I feel the same way. I, I have no need to I have no need to change mine over. I'm very satisfied with how Mongo works for us.

And, just like you, on each project, I would assess something different. In fact, the database I may be most likely to use right Node. It might even be well, it's not a database because it's Postgres, but Hasura and Postgres together seems like a nice little treat for me, but I'm not I'm not I'm not gonna move my database. Not a chance. No way. Not gonna happen. I think that's

probably the next step of the database that everyone uses is it's gonna be something that comes with another layer. Yeah. That gives you a GraphQL API on top of it. Hasura Prisma, MongoDB is rolling out their own version of this.

We're starting to see that become a little bit more popular because, I don't know, I think people are pretty happy with the solutions of databases out there unless you're, like, running Twitter or trying to like, I know, like, someone like Drip. They have to log millions of actions per second of just things people clicked on and hovered over and and things like that. If if that's the case, then, obviously, yes, look into that. But if it's the case of me and Scott, we're we're just saving records for people, that's a very low, Bos. Almost any database would be able to to handle that. Yeah. I feel like sometimes people, they do maybe

not understand exactly what our requirements are Vercel other other people's requirements. Because our our at the end of the day, our requirements are really not that intense.

Right? We're we're serving a fair amount, but we're not serving, like, streaming data a ton. We're not doing a ton of crazy stuff. And at the end of the day, man, Mongo's great. I don't I know there's a lot of hate around Mongo occasionally, but I'm a huge fan. So yeah. And if you are starting a new project, you're gonna wanna evaluate your database, and you're also gonna wanna host it on a .tech domain.

With more about .tech domains is wiz.

Yes. So I don't even need to explain what .tech domains are because it's literally in the name. It's a domain name that ends with .tech. So I teamed up with .tech or teamed up. I they gave me a domain name for my users .tech.

So I was like, I wanted to build this website where it compiles everybody's uses pages, which is just go to uses Scott tech. You could figure out what it is. And I needed, like, a short, snappy little domain name for it that clearly said what it was. Right? Mhmm. It shows the technology that we use. So, I I reached out to .tech and say, hey. Like, you're sponsoring the podcast.

Wouldn't it be cool if, our ad reads were just me talking about using .tech instead of having to to go through all the regular ad reads that you have? And they said, absolutely. So they hooked it up, and I thought it was just, like, the perfect domain name for the type of website that I have. I love short little domain names like that. All kinds of other people use it. Viacom, CES, Pnpm, they all use Scott tech for their technology focused domain names. If you want to check it out and grab your own Scott tech domain, go to go.techforward/ syntax2020 and use the coupon code syntax 2020, all Node word, and you are going to get 90% off 1 5 or, get this, 10 years. If you wanna register a domain name, 90% off for 10 years into the future.

Absolutely.

You can go to go to go.techforward/syntax2020.

Thanks so much to .tech for sponsoring.

Cool.

Alright. Next question is from Art Wheeler. Now this question says, hey, guys. First of all, I really appreciate your podcast. Thank you, Art Wheeler.

Lots of great information on digging your humor. So I am very new to the dev world. Went to college for 15 years for computer science, but dropped out halfway through and became an electrician.

Long story.

But I'm wanting to change my career, and I'm very interested in software development.

I've heard about Modern Labors boot camp, and I'm intrigued. I'd like to know what your take is on their program. In the last few weeks, I've listened to half your of your shows. And in the end, you say, and don't forget to subscribe in your pod favorite podcast player. I say that.

I feel like you're referring to the audience JS players, and it cracks me up every time. That is kind of fun. Hey, player.

Don't forget to subscribe, player.

So okay. So this boot camp this boot camp is called Modern Labor.

Have you heard of this specific boot camp? Because there's a lot of boot camps Yeah. Being floated around. I have not heard of Modern Labor. There's a site called Course Report.

I don't know if you're familiar with Course Report.

Yes. Yeah. Oh, yeah. Because I used to teach at boot camps, so I'm very familiar with all of these these websites.

Okay.

Yeah. And there there's not a lot of information on this one. So, yeah, I have not heard about Modern Labor.

And just like many other boot camps, there there seems to be just a ton of them. I have not heard about this one specifically, so I'm interested to know what you have to say about this one. Yeah. So if I think this this

advice I'll give applies to any any boot camp that is out there. So first of all, being an electrician, I'm not sure if modern labor is targeted at people who were in the skilled trades and are trying to now get into tech. I don't think that you need a special boot camp that is targeted at you. Like, I I taught out a boot camp, and we had a guy who was a glacier. Do you know what that is, Scott? He moved really slowly? No. He JS, a glacier. I didn't know this. Someone who works with custom glass.

Oh,

okay. Know that. Now you know. Interesting. Know that. Yeah.

So we had lots of people coming from construction, electrician, plumber, things like that. And it's Sanity. We also see the opposite. People leaving Wes dev and getting into skilled trades because that's certainly a a good industry to get into. So I don't think that you necessarily need that. Now what should you do when you're evaluating a boot camp? First of all, I think you need to go on Reddit and and see what people are saying because Real people. Yeah. If you go on any boot camp's website, they're gonna have Scott of nice Sanity stories and things like that, but you need to find the actual the people that actually took it and are willing to share with you firsthand experience as to how it works. Now with that said, you're gonna you're gonna get people on either side even on Reddit. Like, you you're gonna find people on Reddit that are, like, awful, teachers were garbage, things like that. And that's just because there's the reality is that in every boot camp, there's a couple people that just it's just not for them. They can't kick it, or it just didn't. Whatever was going on in their life at that time, it didn't work out. And then at the same time, you're you're also gonna have boot camp people who are told by their boot camp, hey. Can you go talk on Reddit about us? Mhmm. Something like that. So you just gotta, like, take in as much as you possibly can about it. It doesn't seem like there's very much information about this boot camp online. So for that reason, I would probably steer clear of it because these boot camps, they need years to make really, really good content.

And if you are, I actually taught the very 1st boot camp of the one I went to, and it was really hard to put it to make the content. And I know that, like, the content that you are taught in the boot camp is probably one of the most important things along with the instructors and making sure that you enjoy the instructors and and how they talk, how they explain things, and and whatnot to you. So there's that.

Also, you need to know now know that a lot of boot camps are doing ICS, which is called income share or ICA, income share agreement, where, generally, it works in the fact that they either give you a discount to the boot camp, they give the boot camp to you for free, or they'll even pay you to go to the boot camp.

And then in return for that, they will take a certain cut of your salary over the next however long. And most people's initial reaction to this JS, that's robbery. Why would you do that? But I've I've talked to enough people that have gone through this. And if it's done well, I definitely think that this is is kind of a cool way because, like, certainly, some of the good ones that do this can help you negotiate a much higher salary because it's in their best interest to make sure you get paid well. And there there's a limit of of how much money they will actually take from you over the next 5 years and whatnot. So, I don't know, kinda interesting. Yeah. Boot camps are fascinating. They're they're fascinating because it is tough to know with any of this stuff, especially if you're not going through it. You just don't know.

And, again, I I'd like to do that, like you said, just to add Reddit to the end of things. Like, if I'm searching for something and I wanna get opinions, I'll be like, best, blank, Reddit, and then they'll you'll see a comment thread of a bunch of people talking about it. I think that's important. I think that that stuff does help, quite a bit, at least, understand real world perspectives. But who knows? It could all be fake. I mean, you never know. That's a Reddit is very good at filtering out

a lot of the skeezy people. It certainly still does happen. Like, sometimes there's there's a subreddit called hail corporate Yeah. Which is is just people calling out people from, like, corporations trying to pose on Reddit, but it's one of the few places that haven't been tainted by sponsor money like Scott and I have. By the way, make sure you go to .techdomainnamesandlogrocket.comforward/intax.

I know. Head over to levelofpro.comforward/pro while you're at it, and, Wes Bos courses, and, just final. Just buy. Excuse me. Let me just get a Pepsi.

Consume. Yeah.

Yeah. So alright. So, hopefully, that answers your question.

Just by doing some preliminary search, I would probably look for a different boot camp. There's so many out there that have been around for much longer than this one, and I wouldn't wanna be a guinea pig in a boot camp's cage. What what are you, a guinea pig in? Perfect. Node. Yeah.

You started the guinea pig thing out of the yeah. Okay. Next question is from, Brad Garepi.

He says it rhymes with therapy, and that's cool. But Brad's a Brad's a super cool guy. He's a he's been a long time member on the LevelUpTuts community and Slack room. He says, suck dudes. Loved your recent episode on serverless functions. I've implemented a few myself, but I always come back to the same question.

How exactly do I secure these endpoints? Because you are charged for compute time and those endpoints are publicly available, couldn't you just have anybody send requests to them and up your bill? Okay. Says bonus. Talk a bit about how authentication works in serverless functions, cookies, Bos, whatever. I know you've been doing quite a bit of work with this sort of stuff, so I'll let you handle the heavy lifting. But I think one thing that you should think about here is that, you know, protecting yourself from these kind of things, it shouldn't be a ton different necessarily than protecting yourself from any other Deno Wes. DDOS? D the depart denial.

Distributed denial of service? Distributed denial of services where people can fire off requests against your website or your server regardless if it's a singular serverless function.

And, although you like you said, you're you're paid by the the usage here rather than just paying, for a service, but, yeah, Deno protection, throwing something like Cloudflare in front of it. I don't I don't have any experience here securing these serverless functions. Wes, I'm interested to hear what you would have to say about this.

Yeah. It's no different than securing, like, a rest endpoint on your your existing application. So how that works with with mine is that I generally have a middleware to all of my endpoints that are secured, and that middleware will then make sure that the person is logged in. And the the way that you do that is you either, there's a there's a session ID in the cookie or there's a JSON Wes token that's coming in in a cookie or in a header or something like that. And in a serverless function, it's no different than that. The fact is that you just need to make sure that that user is logged in. So what that means is that you'll likely have to do a database call in front of all of your secured endpoints.

There are also, just Lambda authorizers.

This is one thing I've not looked into myself just yet, but you can even peel it back a layer before that and make sure that they you they do indeed have the correct authorization headers in the the request that you have there. But, honestly, if I was just doing it today and I wasn't doing an entire website in it, I was just doing a couple little things here or there, I would probably just take in the JWT either via header that's sent manually or via a cook cookie that gets set when the user logs into your application. And then you just check for that JWT.

You look it up in your database. And if it is a good, then you allow them to go ahead and do what they want. And if it's not, then you send a response that tells the user that they're unauthorized to do so.

Yeah. So that sounds about right. I mean, at the end of the day, these are just endpoints just like you're securing anything else regardless of of if there's a 1 singular one or not. Right?

Yeah. I think one thing people think that is bad is looking up the user in the database on every single request.

But if especially if you're using, I know MongoDB will store stuff that you look up often in memory, so it's nice and fast. That's what Redis does as well where you can store things in memory. So, like, the the overhead of looking this up in a database is very low, and it's totally fine to do that. Cool. So next question is from Ryan. Ryan asks, I've decided to make a career out of coding and programming, and I'm an absolute beginner starting on HTML and CSS.

It might be a weird question, but how many or what percentage of elements and declaratives do I need to memorize? It's not that the info is necessarily difficult to parse.

It's the amount of tags that I'm bombarding my brain and muddying my progress. I'm more of a theory driven learner, so it's not the biggest in the world. And I'm starting to see the breadth of this endeavor. I'm not sure how to focus my mental acuity.

Thanks, guys. Ryan, you got a nice vocabulary there. I loved a lot of these words. Bombarding, acuity.

Scott Scott can't even think of the word vocabulary, and Ryan's over here using Bretton endeavor.

Okay, please. I have a fantastic vocabulary and whatever.

So okay. This is a tough one because you have so many properties, and those of us who've been doing this a long time will take this for granted because I've been writing HTML since I was, you know, in middle school or something. And and and because of that, I've had a long time. Okay? I don't even have to think about any of the tags or any of the properties that exist on those tags because I've just been doing it for so long. And same with CSS. For for me, CSS was never that difficult because the properties just seem to make sense. Right? But there is so many properties. And when you're learning this stuff, even if you've come from anything else, you might have a different idea about what this thing should be named. Right? The one that always gets me is, this is so stupid because it's Wes you use all the time anyways, but linear gradient on top of a background image. Like Yeah. Why? Like, they're they're that one's one of the ones that I always, you know, copy and paste from somewhere else just because I don't wanna mess up the syntax. And there's so many little things like that. So how much of this stuff do you need to memorize? I would say as far as HTML CSS goes, you kinda wanna memorize at least the stuff that you're using every day, the semantic, tags, the the headers, the divs, the the mains, the footer, the article, the sections, those big major tags. Obviously, you don't need to memorize some of the tertiary tags. Like, what is it? Like, superscript and and those ones. You don't need to memorize those because they ABG tag. You don't use them that often. Right? So my mind is goes towards write HTML code, write CSS code, and you're gonna pick up on some patterns pretty quickly in terms of, like, the stuff that's used a lot, the stuff that you're having to look up. And I think any sort of memorization of these tags elements CSS properties will happen naturally as long as you're looking up how to do things. Like, I wanna build this layout. I wanna do this color. How do I write a linear gradient? Okay. This is how I do it. I wanna do this font color. How do I do it? Okay. This is how I do it. And then sure enough, over time, all those things will just fall into place.

Did I ever sit down with flashcards memorizing any of this stuff? Absolutely not. And I don't know if you need to. Maybe it could help if you're that type of person, but I would say don't worry about memorizing it. Just start coding cutting more interfaces, and it will come to you.

Yeah. Honestly, I never sat down and memorized anything. If anything, the v s code auto completion makes that all way easier than it used to be. And then just use cheat sheets. So Google CSS cheat sheet, print it out, put it on your wall or whatever. HTML cheat sheet, Flexbox cheat sheet, put all these on there. Like, Flexbox is one that I I looked up for probably 2 years before I stopped having to reference Chris Coirier's

thing for that. Yes. Look. Yes. It's the CSS trick one. I reference that

forever and ever. The whole yeah. It it takes forever. So just just print out cheat sheets and look up stuff as you need it, and, eventually, you'll just do that less and less. I don't think there's a certain amount that you have to memorize and certainly never did that either.

Yeah. Totally.

Next question we have here is from Luke.

Do you have a standard folder structure for placing utility functions utility function JS files? Is there an industry standard? I've been using utils, utilities inside source, but curious if there is a more common way.

I usually make a folder called utils.

And then inside of that, I will just put if it's a small project, I'll just have an index Wes and put them all in there. And if it is a larger project, I will do a new file for every util function.

And then I'll just export them out of there and then import them into the pnpm j s. And that allows you just to import them directly from the utils folder, and it it works really good. Yeah. I do utilities.

I spell it out for some reason, and I do so I have a server side utilities and a client side utilities. Utilities for me are always just those functions, single functions that have a single purpose that do one thing and do so in many parts of the site. If it's like a specific utility function, like something, related to the shopping cart only, I'm not gonna put it in my utilities folder. That's gonna go in something more specific to the shopping cart, like maybe shopping cart utilities within that feature folder. Because if it's not being accessed outside of that section of the site, I don't really want it to be available throughout the entire site for no reason other than organization.

I do mind, like, we frequently talk about on here with an index file, an index file that imports and exports all of the things from the folder. So that way, instead of importing blank from whatever, I'm importing everything straight up from utilities.

I also as we mentioned in the last episode, Node think it was with one of the one of the previous episodes, I do so with a babel module of resolvers plug in so that my utilities folder is just available under the name utilities as a module resolver.

But, yeah, I don't think there's any sort of industry standard. I think, you know, utilities in general is one of those, like, just toss it in there sort of things. You Node? Like, everyone's is different. Yeah. I always I always wish that there was a standard because when I was first starting,

I was like, where do I put this? Like, what is this even? Is this a Lib, or is this a utility? You know? And they I always see people using that, and then there's a source director. Like, what? Like, what is this? And then I realized that everyone's just making it up,

and it doesn't really matter, at the end of the day. There's there's no, like, upside or downside to that. That does matter, though, when your code is, has bugs in it. That's what matters. Right? Hey. It matters when you create these bugs in it. So you wanna you wanna fix those bugs, and you can fix those bugs way easier with something like LogRocket than without it. Now what is LogRocket? Well, you're the one who do logrocket.comforward/syntax, and you get 14 days for free of this service. Now this is a service that does some really amazing things. It gives you a session replay of what exactly happened when the user committed a bug. So let's say I click on something, it breaks. And, typically, you just are left to either a error log or anything to tell you what happened. But now you can see visually what happened that caused this thing to break. You get a session replay, scrubbable video with a Redux store console log errors, network activity.

And even more than that, it works with everything you know and love already, GitHub, Trello, Jira, Salesforce, Zendesk, Drift, Intercom, Sentry, Bugs yeah. Just endless amount of things it works with. So check it out at log rocket.comforward/syntax and watch your bugs happen.

Alright. Next question is from Andrew.

Andrew says, is figuring out new tech module plug ins or whatever really as easy as reading the docs for most people? A common response to what's a good way to learn is to seem, well, the docs are good, and then I open the docs and I'm absolutely clueless. Are these people giving bad advice, or do the docs actually give most people enough to go on? For example, I tried to implement a user login with Passport using their docs. A lot seems to be left out, implying that you're supposed to just already know this stuff. If it's a bit demoralizing to feel like I can't figure out anything on my own, I've been doing web dev for a few years Node, although Scott professionally. I have done some big projects and that are used regularly.

So, anyway, just wondering, what's your take on common advice and your experience being able to figure out your things on your own without needing an hour long tutorial and so on? I know you're both tutorial makers, but I don't get the impression that you 2 take have to take a course to understand something new. Okay. So this one's interesting because it's one of the reasons why I even created Vercel up tutorials in the 1st place was that, there were so many things within the Drupal community. It's like just install this Drupal module, And you're like, okay. I installed the module. Now what? And sure enough, you know, you need to click here and whatever. But, Drupal people were never honestly the Scott out to Drupal people, but you they were a lot of people were never the best at coming up with these amazing user experiences to just know what to do. And so I agree with you here, Andrew. A lot of times, I'll hit projects too, and I'll think, wow. These docs are leaving so many things out.

Even, like, leaving out the things that they just assume people know. Right? And that is a really difficult situation for a lot of people to learn it. Now some people are we have a lot of different types of learners. Right? Some people are gonna hit up the docs. They're gonna read the docs. They're gonna have an idea of what to do already. They're just gonna get it done. Other people go straight to the source. They're gonna look at the source. They're gonna read the source. They're gonna understand what exists, what the application Node. And other people like myself are gonna maybe go towards more exploration.

You know what I do? I just start throwing stuff, the code in and get the errors, try to solve the errors, try to figure out why it's not working, and I do so that more than reading the docs. In fact, a lot of times before I even really heavily read the docs, I just start tossing code in. And then if it breaks, then I'll go to the docs. Other people, video tutorials, blog posts, whatever, there's a huge range of what really sparks people's, you know, brain correctly working to understand, what these libraries and applications are doing. So don't get down on yourself about that one. Yeah. I agree with Andrew. Most of the times,

the docs are very hard for me to learn on. I much rather go into the examples directory and see how it's actually done or watch a tutorial from someone to see how they have implemented it it themselves. So don't feel bad that the the docs are.

I I find that the people that say the docs are good are very are usually advanced developers who are good enough to just Totally. Be able to look at it and say, oh, I understand. Like, I have all of this back understanding of how this ecosystem works, so I see how I can implement it that quickly. And and that's generally what the the benefit of it JS. And that's also the docs are a place for you just to reference different options Node different methods and things like that, where how do I actually implement it myself is something that a lot of docs will leave out.

React and Gatsby docs are really good at showing you how to use this, but, still, a lot of times, people just want an entire project to be able to do it. So so don't feel bad about that. I'm certainly only at the spot in my career where I can read the docs, and then there's this another level where people look at the source to figure out what's going on. You know? I occasionally will pick the source over the docs

because the docs assume you it it really depends on what the source is like because sometimes source is really difficult to parse, and it's it's littered. And I don't wanna say littered because a lot of the stuff is important, but it's littered with a ton of, like, really long comments explaining things. And to me, that, like, gets in the way of just, like, seeing what the code is. If it's a React component, oh, yeah. Source all day. I wanna see what they're doing. I wanna dive right in. If it's, you know, a 3 d modeling library, no. I don't care. I don't I don't wanna see it. Totally. You Node? Just just hide it away from me. But, yeah, it really depends, I think. That's true. I actually had a a right before recording this, I had a syntax error, and it was saying, like, cannot get property or whatever.

I see. There you go. Yeah. And it was funny because I couldn't find the error anywhere ESLint. So I finally just searched that syntax in the thing, and I found the actual code in the, I found the code in the source and I was able to actually figure out. So maybe I do sometimes see that as well, but Node not like some people I see who who just immediately crack it open and say, like, this is how it works. Sometimes people even send me just, like, chunks of the source and be like, this is how it works. I'm like, what? Node.

Squeeze me? Yep. What? Squeeze me.

Next next up, we have AJ.

Do you have any tips for getting over Node shyness or impostor syndrome? I find myself struggling with this from time to time and was curious to know your suggestions for dealing with it. PS, I love the show and learned a ton from you guys over the last year.

I think we did an entire show on impostor syndrome, didn't we? If we haven't, we should. I think we've talked about it a few times. Okay. Episode 58

and episode

15. So we haven't done 1 in almost 2 years now. Maybe it's time to to do another one. It's always been, like, not like the focus. It's always been just like a pinpoint in another, like, larger topic.

Yeah. I think just being okay with not knowing everything and just being able to put your code out there for the world to see, You certainly are going to get run over a few times by somebody who thinks they're trying to help. It happens to me almost every single day when I post a screenshot of the code I'm working on. But the reality is is that almost everybody else is in the same situation where they're they're afraid. It's the same thing with, like, when someone launches a project or a personal website, they always preface it with, it's not done yet, or I only had a bit of time to do with this, or it's not perfect. I still need to to redo this. And they're they just, like, kinda preface it. Like, don't kill me, please. And I think that's that's something to say to the community is when somebody is sharing something, when someone is putting their work out to the world to see,

like, be nice and and try to provide providing feedback is good, but provide it in a a positive manner. We have an entire show on providing feedback as well. So Can can we just say that as a general note? Just be nice. Just Just be nice. Just be nice to people. Right? What's the harm of being nice and having empathy to people? Yeah. There's no harm. Just do it. Yeah. Yeah. Everyone struggles with it. I certainly do myself, especially

when I dive into different areas. Like, I'm doing React one day and Node one day and Gatsby. I'm I'm, like, in all kinds of different areas, CSS. And, certainly, whenever I dive into those, the experts of those areas come out of the woodwork.

And sometimes it's very intimidating because it's like, sometimes Brendan Icke will will tweet back at you, and he literally created JavaScript. Right? Like, sometimes those people are are very kind. Sometimes they're not. But But you just gotta be like, you know what? I'm trying to build websites here. Who cares? Let me put my work out to the world.

Totally. Totally. Totally. Totally. Yeah. I mean, I personally you know, I'll have days where I'm really struggling with this, especially putting out this content and just being like, oh, I'm just like, you know, I I wish this was better in these sort of ways. And I think a lot of times, those of us who feel this way about our work, right, we don't realize is that it's important part of becoming a better developer.

It's an important part of the whole process because if you are feeling like things should be better or that you need to learn more or that you need to get better in these sort of ways or your code isn't as good, it's a driver to improve.

And what you can't let it do is you can't let it put you down and you can't let it stress you out in ways that negatively affect your life. But if you can take a step back and look at it JS like, alright, I am not satisfied or I'm nervous about my code for these reasons, you could take a step back and say, okay. That's an indication that I really value the quality of these things. And then I really want it to be as as best as possible. I know, my wife, Courtney, she she's a a doctor of psychology, and she tests a a lot of children for different learning disabilities. And they do these big, long tests, and then she does this giant write up. It's like, you know, Node I don't know. It's, like, 12 page write up. It's long write ups about, like, the test results. And every single time, she's like, I just wish it's I just hope it's it's gonna be good. I don't think the parents are gonna like it. And then every single time she gets back glowing results. I'll tell you the reason why she gets glowing results is not because she's anxious about how it's it comes across or whatever, but because she has that insight to say, like, I just want this to be so good. I want this to be so good. And I I you know, that that, like, drive to, like, wanna make things that much better is really what turns you into a good developer.

So, don't don't let it consume you. Don't let it don't let it, rip you apart that way, but really just try to see exactly how it makes you better.

Last question is from Tim Smith. If I rename my GitHub repo, will all the links that are in the wild still work? For instance, github.comforward/something, and I map it to github.comforward/annewsomething.

Wes, your answer, you Googled it.

I was actually always wondering this as Wes. So I finally Googled it after thinking about it for years. And, yes, you can rename your Deno, and you can rename your username, and GitHub will redirect those to other people. Although there is the option that someone could register your username if you change it on GitHub and then make the same Deno, so you you have to worry about that. But, yes, you can do it. It will go.

Cool.

Okay. Nice.

Well, I think that does it for the Alright. Sick picks.

Yeah. Let's get into some sick picks here. These are things that we pick that we find to be sick. Do you have one off the top of your dome, or do you want me to go? Okay. Let's get it. I think this is something you've used for a long, long time. I recently just got it, and it's the I Scott menu

for OS X. Fantastic. Yeah. Yeah. It's so good. So what it is is a little menu bar application where you can put your I I initially got into it because I noticed my GPU was just pegged all the time, and, it will tell you what is using up your GPU processes, and your CPU processes. And then, also, I use it for I constantly have my up and down bandwidth because I live in a a country where there is no bandwidth available to me. And sometimes when I'm talking to Scott, our video will start glitching, and it's because I've got something running in the background that's hogging the bandwidth. So the question is, what is hogging my bandwidth? JS very quickly, you can very quickly see what is hogging the bandwidth with ISAT menu. And there's also, like, weather and RAM and all that stuff. I don't care about that. It's just GPU, CPU, and up down bandwidth.

You know my favorite part about Istand menus is that you can change the color to be whatever you want.

You can.

You can get really in-depth

theming it. It's like $11 too, and it does so much. I I can't believe I live with this Scott live without this for so long. Yeah. I'm a huge, huge fan, a big, big fan.

Love it. Absolutely love it. Cool. Well, my sick pick is going to be a podcast that I've been really enjoying, and it's not like a one of these story driven podcasts that I've sticked before, but it's a fitness based podcast. I like fitness stuff. This one is a new one that I started listening to. It's called Stronger by Science, and it is definitely weight lifting focused more so than anything else. But they do such a good job of really going in-depth. And these episodes are long. They're like hour and a half, 2 and a half, 3 hour long episodes. So if you don't have the time for this kind of podcast, I'm slowly going through it, obviously, because they're long. But I I found there's 2 dudes talking about science based stuff about around lifting. So if you're an intermediate advanced weightlifter, interested in any new podcast, Stronger by Science,

JS really nice. I've been liking it. Awesome. That's pretty cool. I have way too many podcasts now that you keep recommending them. But Yes. I know. I'm sorry. I am a podcast. I love podcasts. Yeah. Big fan of podcast. We run our own.

Shout out to podcasts.

You should listen to syntax.

Yep. Yep. Alright. I'm going to shamelessly plug all of my courses at westboss.comforward/courses.

You can check out a list of all the different JavaScript and CSS based courses that I have. Use syntax for $10 off. Cool. I'm gonna plug

my latest course, which is, animating React with Framer Motion. We build all sorts of really practical application interfaces with Framer Motion. It's really super cool. Check it out, level up tutorials.comforward/pro.

Sign up for the year. Save Wes.

Alright. I think that is it. Thank you so much for tuning in, and we will catch you on Monday.

Peace.

Peace.

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