The Future of JavaScript Frameworks × Building Auth × DB Design Tips, and more!

Welcome to Syntax. Today, we got a potluck for you, which is we bring the answers. You bring the questions. Today, we're talking about the future of JavaScript frameworks, building your own auth, how to limit API access, Sanity server proxy. I show a little bit of my own code passing components as props or as a child in JSX. And finally, we got some, interesting questions around how should you structure and and design your database, relational database.

That's it. So let's get on into it. Welcome, Scott. How are you doing today?

Oh, man. I'm doing super good. Just got back from a rousing trip to the airport, which is, like you know, the the best thing to do first thing in the morning is to drive out to the airport.

Oh, yeah. In Denver, it's it's okay. You know? But it is, like, 30 minutes without traffic. And then the moment you start hitting traffic, it's, like, really intense because it's mostly just, like, 2 lanes and stuff. So Brutal. Yeah. Definitely wake you up first thing. Yeah. For sure. What's this shirt you got on Vampire Weekend? Oh, yeah. I went to, the Vampire Weekend concert at Red Rocks last week, and, man, somehow, I don't know how, we got front row tickets mostly because when, we were, like, right right at the the dot to buy the tickets, but all of the cheap seats sold out so quickly, We're like, I guess we're getting really close. And we we bought them in the 2nd row, but it turns out the 2nd row at Red Rocks is actually the 1st row. And they were normal concerts. You Node? They're, like, above you or something. They were, like, right at eye level and just, I don't know, 40 feet away from me, if that. It was crazy. Just had a a big old smile on my face the whole time, man. What a what a cool thing. And even CJ was 3 rows behind me with his wife there, so we got to see them and say hi. Yeah.

That's awesome.

Yeah. I love that. Cool. Alright.

Should we do a century

thing? Oh, yeah. And if you wanna be able to go to a concert and have a peace of mind to know that your application's running successfully without too many things going haywire, you need a a service or software to make sure that the software that you're running is bug free, and you can track and keep a handle on all the bugs. But, also, stay on top of regressions or potential things that you thought you fixed, but maybe you didn't. For instance, Wes, I just rewrote our whole caching system to fix, well, for 1, the API wasn't great. Yeah. 2, it was to fix some Sentry errors that we were getting about the, you know, Prisma validation stuff. And so I rewrote this whole thing, and I was so confident that the caching system JS what was causing those errors.

I didn't really dive in close enough to check, and then sure enough, they popped up as a regression. So I'm gonna have to look elsewhere because I don't think it's I don't think all of the Prisma validation errors were coming from the cache system, just

some of them. So now I gotta dive into those a little bit. Interesting. I I I love that about Sanity where you can just, like, mark it as resolved and set it off into the c. And Yes. You say, I hope I hope I never see you again. And sometimes it comes back like a boomerang.

Hits you right in the forehead. That. Yeah. Yeah.

Oh, actually, that's a question I have for you JS, like, probably for the first, like, 5 years of me working on my platform.

Whenever I would go away for, like, the day, you know, like, I would go visit my parents or we would go away for a day trip or something like that, I would throw my laptop in the car just in case something went down. And over the 5 years, I don't know, maybe 2 or 3 times something would would go wrong, maybe a bit more than that if you asked my wife. But every now and then, I would just go, hey, something's something busted. I'm on call all the time. It's my Yeah. It's just me here. And I I realized the other day, like, I haven't been I haven't done that in a long time. Obviously, if I go on, like, a a more than a one day trip, I'll throw my laptop in the car just in case. But, like, did you do you ever do that? You ever take your laptop with you? Because I was very scared to have my whole thing be down and not be able to to fix it, especially after the horror stories we read on this show.

There's been times that I've had to pull out my computer at the the ski lodge. I would take it if I was taking a ski day because I I used to go up on Tuesdays. There's been times, I was at a tea and tea and biscuits thing, and I had to pull up my laptop. The whole family's there. I'm like, I'm sorry. I have a sale going on. There's clearly an issue. I'm getting some alerts going.

Yeah. I I gotta I gotta fix this. So yeah. No. I I very much feel like that weight off my shoulders these days, which is an intense feel. Sorry. Before that, if you wanna Yeah. Get all this, century.iosentry.i0forward/ Sanity.

Sign them again 2 months for free. Alright. Let's get into it, Wes. Alright. 1st question from Abdul Rahman. With so many JavaScript frameworks available, how do you see the landscape evolving over the next few years? Which frameworks do you think will gain more popularity and why? Oh, that's that's a good question. And and the, like, what do you see the future questions are always tricky because, I don't know, we're we're just guessing who what the future looks like. But what do I think the future of the JavaScript looks like? I think that we aren't going to see a whole lot of shakeup, but I I do see that now that we're hitting React Server Components, a lot of people will have not a significant rewrite. But it's a big enough bump in the road Wes enough of a bump for people to consider moving to something else, especially to frameworks that support JSX because a lot of people will be looking at it and be like, well, I could move to solid or a solid start and still keep 81% of of my code base. You know? You kinda like Or knowledge. It's just general knowledge. Yeah. Yeah. In my knowledge, like, the the templating is it doesn't need to be redone. In some cases, the the states maps 1 to 1, but then I can maybe use my maybe start using signals and whatnot. So I think we'll see a little bit of that, not a whole lot. I think we will start to see those things that people look at other framework and say, man, I wish that React had that. We'll see see those features landing in React, I hope. I don't know if this is a a guess or a or a prayer of mine to start seeing that, but, honestly, like, which frameworks do you see? React will still be big. I think SvelteKit is going to have a big come up. I think probably Solid is gonna have a big come up as Wes. And then I think Astro is Astro's been blowing up for a a year now just really gaining some serious momentum. I think it's gonna I think it's gonna continue right, up on that trajectory.

Yeah. A big yes to all that. You know what? I I totally agree with you, and I I do feel like Solid is one of those things that if people really gave a a try to more, they would really, feel the the vibe, especially if you're coming from the React world simply just because so many of the skills are transferable, but you also get so many of the the lovely things that are lovely about compiled languages in general. So, yeah, I I do love the idea of solid, getting more use in general. I I think you nailed it with Astro. The one thing that I would add on to all of this is I do think, deep down, even if we're not seeing it quite yet, I do think Deno down that the web component space will take over more of the elements that we end up writing in Yeah.

React right now. I think it solves a lot of issues.

I think it's standards based. There's a lot of things to like about it. I don't think everyone has to author web components to make web components be viable. I think it's, like, you're probably going to be consuming them more as additions, extensions onto the HTML platform. And so that's the thing that I will add. Now, selfishly, I would love to have Svelte and SvelteKit really not not, like, take over because I don't I don't need I don't have anything wrapped up in that where I need it to be number 1 or something. Mhmm. But I would like more people to try it because when you try it, you really, like, dial into the simplicity of values changing rather than components rerendering.

And that's a big thing to me. Not only that, but it it does feel very web platform.

So, yeah, I, you know, I I I agree with just about everything you said and add on to it. I could see web components being used more often, especially once this was it Wes Awesome? That's what it was called Yeah. With the the shoelace folks. Once Web Awesome hits, I think people are gonna be diving into that. I can't wait, for Web Awesome because yeah. Like like you're saying, you're not gonna be writing Wes components yourself, but there's going to be this just bevy of prebuilt,

extremely functional components out there where you can just grab them, slap them in. It doesn't have to be a, like, a React version of everything or a Solid version or a Svelte version of everything. It's just gonna be a solid web component that you can slap in there, and then you can sorta take it from there.

Yeah. And the best part about that is, again, you're not shipping a library for those. You're shipping Yeah. The, you know, the web. It's able to work with stuff. So I I could see that definitely being a thing. And I I hope it is actually because, you know, HTML elements are great. And if you get an extension on the HTML elements that are just, like, prebuilt for you, then why not? Next question from friend of the show, Ali Ali j t. How do you use a service like Caddy for local development alongside a modern framework like SvelteKit? Can this work with a Vite development server or only traditional apps? This can absolutely work alongside. Wes has actually he pulled up some code here. So if you're listening on the radio, Wes has pulled up a video. You can get the video version of this podcast on both Spotify as well as YouTube if you want to check out what we're showing. But Wes is showing off his CADDIE file and how you can do this. Now for the most part, it's not too difficult. There is some feature specific complicated than it needs to be. It's more complicated than it needs to be, but it's a copy and paste, really.

Yeah. Do you wanna explain what you have? Yeah. So

the way that CADDIE works is that it will proxy. We thought we had a whole show on this. You can go back and listen to the local development proxies or or sorry. Self hosting proxy show we did. But the way that it works is you essentially set up a local development URL, and Wes recommend using the dot local host TLD. And what that will do is it will give you a you can just say, like, my app Scott local host, and what that will do is it will proxy through your actual application. So in my case, my Vite server is running on port 7777.

However, I can then access it on boss monster Scott local host. And in fact, I've taken it a little step further here and said anything Bos monster.localhost.

This is a why wildcard domain there, and what that allows me to do is because I have so many domain names for my courses, it allows me to go to TypeScript.

Bos.

And in my app, it'll deliver the the contents depending on which domain name you're visiting.

So it's as simple as that. Almost always, your Caddy file is going to be, like, a 3 liner. You can even do it without even having a Caddy file. It's with just a I think it's just like a a Caddy CLI command that you can paste in. But mine's a little bit more complicated because I had just have some some baggage from years past where I need to proxy multiple servers. So in my case, I'm proxying the Vite servers.

I am proxying some of the Vite stuff for React Refresh, and then I also have an Express app running on port 3333.

So it's proxying that, which is everything else.

And then I also am proxying the WebSockets that come through Vite, and then I also am proxying my my admin. Because I have I have 3 servers in my application, and I'm proxying them all through 1 tidy domain name, which is pretty nifty. So, again, this is much more complicated than it needs to be, but shows you how you can sort of take multiple servers that are running locally or or not not even locally. They're running on a server somewhere, and then you could proxy them all through 1 single clean domain Node, and it's really nice.

Yeah. So to be clear, it it doesn't need to be as complicated as yours. You may hit some that WebSocket issue in which you'll Google it, and you will find a GitHub issue that I made about 3 years ago, and it has a solution in there. So it can be really simple. It can be very Node, and I honestly like it. We we talked about this in the reverse proxy episode. Like, sometimes things get wrapped up into local host port 5347 or what it is. But do you do you know what it is offhand? I don't know. 51,

fifty four, whatever, the, like, default Vee port. Yeah. Yeah. Whatever it is. And

you get things like cookies saved to that. You get things like local storage or, service workers stored to that. So actually having unique domains for each of your your apps in local host is great. Another one is Safari doesn't really consider local host as being a a secure context, I believe. Either way, I don't know if that's the the full story, but Safari will not save HTTP only cookies in local host. So you do need to have a Oh, okay. Domain for that. And I believe in even an SSL for local.

I I had a whole thing on that in my auth course Wes it's like, here's how to get Safari working with cookie based auth if you need that. So It's just a pain. And, also,

sometimes like, local storage, a secure origin, one of them includes the port as the origin, and one of them like, I think it's it's cookies versus localhost. 1 of them doesn't include the port, which JS, like so if if you set let let's look it up. Do our cookies set on all ports? Here we go. Cookies given a host are shared across all ports of that host, even Yeah. The usual. So, yeah, if you set a cookie on port 6666, it's going to be available on port 3333, and and that be annoying if you're working on multiple applications that have the same cookie name.

I'm I'm working on a ton of applications that have access token, refresh token as cookie names. And every time I switch context of what app I'm working on, I have to go into my application. I gotta look for cookies. I gotta Nukem. I gotta refresh the page, re log in, and that's just like that's a that's one of those things that just, like, takes you out of the flow of whatever you're trying to do. It's annoying. So yeah. Use use Sanity. Get a get a local domain name and a a self signed local certificate.

Next question we have here from Chris m. When building a back end for a website, to pull from the front end to those third party resources directly? So the example here is that if you have a website and you need to go to he he gives the example of Clockify.

He has a Strapi CMS where he's pulling his data through. But if you need data that is from a third Sanity, like, let's say, you need to get data from GitHub or you need to get data from, like, a recipes API, does it makes more sense to proxy that request through your back end, or does it make sense to go directly from the browser to that resource? And the answer JS everything in in web development JS, it depends.

Generally, you are going to have some sort of access tokens, which do not allow you to make that request from the browser directly because that would be a security issue if you were to put your access token. So almost always, you're going to be proxying that data through your own server, and that's really nice because it allows you to cache that data. Sometimes you only get, like, 60 requests per hour or 60 requests per day. We have that with the ConvertKit API where we pull for a list of our newsletters, and then we render out a page, syntax.fmforward/snackpack.

Make sure you go sign up for our newsletter.

That list of newsletters is pulled from the ConvertKit API, and it doesn't make sense for us to ping the ConvertKit API every time somebody lands on it on the client side. We do it on the server side, and then we cache that result for an entire hour or something like that. So we are only doing it at most 24 times a day. And then you also aren't, like, bringing any extra data that you don't necessarily need.

So I would say in most cases, it's better to proxy it through for security, for the actual data that you want, as well as for caching in for speed. Where it doesn't make sense is where that request is done per IP address. So for example, GitHub's API will limit the number of requests by the IP address. So if somebody was pulling in, like, a list of, repos on their GitHub, your server would only be allowed to do that, I think it's, like, 60 times an hour or or 30 times an hour. Whereas if you made the request directly from the client, if Chorus allows for it to be done, then that each single person that visits to your website or at least each each person on the same IP address will be allowed to make all those requests. And in that case, you get a lot more requests per user. That can only come and bite you if you Yarn on, like, a a university network or something like that Wes I've had it many times where I do my request timeouts for, like, sign ups on my courses per IP address.

I often get, like, emails from people who work at universities being like, hey. We're trying to sign up as a class, and there's 400 people in my class right now. And then it's it's blocking them. It's shutting them down because they're making forward requests per IP address.

Word. Good answer. Next question here from Casper.

And I just wanna be clear before I read this question. This is not a plant. This question was not planted. This is a real question from a real person.

He says, Scott, where do you get your amazing T shirts? Specifically, the webmaster and the blazing fast ones. I saw you wearing at JS nation and have been thinking about that shirt since.

Casper, I'm so glad you asked because that's right. This is this is I swear this is not an an advertisement, a place question, or anything like that. So we actually have a store, Casper. It's at century.shop, and it has all of these shirts and more. The Webmaster tee is one that we made in limited production and released twice, and they sold out very quickly. That's not to say it won't be back. In fact, we have possible plans to bring it back at some point here. So if you want to, 1, get a discount on on swag at the store or, 2, know when this stuff is going to be coming out so that way you don't miss the boat, hop on our newsletter.

And that newsletter is syntax.fmforward/snackpack, or you can just go to the website. There's newsletter sign ups all over the place or even the shop. There's newsletter sign ups because we let the newsletter folks know first when new things are dropping. We also have, we had Drizzle T shirts, Prettier T shirts. We did a collab with them. A Sick Pick T shirt. That's really sweet.

A skateboard.

A really awesome basketball with hand done graffiti from a really incredible dancer, breakdancer that I know personally. And, yeah. So just a lot of really cool stuff. So check it out. Century.shop.

Yeah. Check that out. The basketball is really Scott. Man, like, there's so many incredible. So many cool things. And, like, this stuff does super well even if, obviously, you're not playing basketball or skateboarding.

This is really good. What I call JS background fodder. So when you have a meeting, something pops up, and it really helps when you when you jump into a meeting with somebody who, Scott Scott, is there, is you don't necessarily know all that well. It's really it really says, mic. But if you don't have the mic,

the background stuff works well as well. I I get that all the time. Or, like, you hop in on a call with a a normal person, and they're just like, woah. You got the whole setup. Yeah. It's like yeah.

Especially when you radio. Okay? Like, someone like a insurance agent or something like that. Yeah. Like, oh, wow. Like, I I What do you do? We get some. Yeah. Yeah.

Awesome. Alright. So, yeah, thank you for that question.

Certainly, check on all those T shirts out. The blazing fast shirt was I'm very happy that that one's doing well because that was so expensive. I made this, like I guess Wes haven't even talked about it on the the show yet, but the blazing fast shirt was kind of a ridiculous design, you know, sort of a play on NASCAR and whatnot. It has all the open source logos, and I had to, like, message, like, a 1000 open source people to ask if we could use their logo on the t shirt. But that one came out so well. But it was very expensive to print because it's, like, full color,

full print, hugest huge print. Yeah. And we haven't actually been talking too much about the merch in general on this show. But, like, one of the cool things about our merch in general is that we're not seeking to make a profit on this. We're not, like, trying to to hosie on it. So, yeah, you know, the the the shipping prices we know could be better. It's hard to have too much control over that. But we're, we're trying to keep the prices as low as possible for everything again because it's it's not about making a profit.

Century does not need the $1,000 a month or whatever we'd make off of the shop. So yeah. Oh, some of them are even are even sold at a loss, which it it doesn't really matter all that much, but it's just kind of a fun thing we do. And the drizzle and prettier teas, plus a couple more to come pretty soon, the money goes towards the open source projects, $10 per tee, which is really cool. Next question we have here from Dennis Glassberg. Hey, Scott. And Wes well, I have people always call me West.

Tech dad question for you. Any screwdriver recommendation that works best for your kids' toys? Yes.

I, unfortunately, don't have it here, but I've sick picked it in the past. It's called the Pick Quick screwdriver, and I think this might just be a Canadian thing. Because whenever I look it up, it's only in Canadian websites.

But this is called the Pickwick 6 Pack Plus, and they sell these little screwdrivers. That's not even, college.

That's a that's a classic Wes joke. I'm sorry. I I had to. I like that a lot. These screwdrivers are really cool because the bits go in the handle.

I always lose my bits. Like, my socket set, I've probably owned, like, eight socket sets over my life because I just I lose them. And Of course. And then I just buy a new one. And this one has been so good for me because in order to get a new bit out, you must push in the old one. So there's, like, there's, like, 6 bits in the handle. And balances.

There's 6 bits in the handle, and then there's 1 in the in the driver. And in order to pull out a different one, you must take the one that you're using and use it to push the new one out. So it it forces you to keep them organized. They have a little stubby one, which I really like. There's a a Maltique one, which I'm realizing these all have very French names. They have it in in USA Amazon, by the way. So Oh, do they? Okay. ESLint for us. Yeah. Go get it. The maltique is, like, a smaller version, and that's our junk drawer, like, a kitchen screwdriver. It's great for kids' toys. It does, like, kinda smaller screws. And then I have, like, the little stubby one. I I keep that in the glove box in the car because every now and then, that sort of stuff pops up. So big fan of that. I am I do want to try out the Linus tech tips screwdriver because that is ratcheting, and I think that would be pretty nifty. I just have not I'm not broken down because I've got a couple quick sick facts in around the house, and they've been Mhmm. Fantastic.

Yeah. I I have I think the this is a lot better than what I have, but I have a an old snowboarding screwdriver that was like a a tool that you'd keep on you on the mountain to tighten your stuff if you need it. And it was ratcheting, and it had all the bits ESLint the handle kind of like this. And and I gotta tell you that ratcheting, really does.

Is pretty sick. So Yeah. Yeah. I'll have to look up this Linus Tech Tip one. Yeah. I got a couple, like, ratcheting ones, but they all the bits are just like those tiny little ones, and they always fall out.

Mhmm.

And they, like, rattle around, which I I don't like any of that. And I I think the line of Secchips one solves all of those problems, so it seems legit. I think I'm gonna gonna get it at some point.

Sick. Alright. Next question from Dan Chowniere, which Dan, thank you so much for providing this pronunciation because his name is spelled c h o I n I e r e, and I would never have gotten that. So shout out to you, Dan, that rules. Dan says, would like to hear your thoughts on DB design database design. I'm mostly front end dev, but have been playing around with some back end stuff on the side projects.

I've never had to go through the process of planning out DB tables and relations between them, and I'm finding it to be much more complex than I thought. Curious if there are any strategies or tips in planning out a web apps database.

Yeah. So, Dan, I come from a world where the database I worked in primarily was Mongo, and the strategy in Mongo was to just nest it all. Nest. Nest. Nest.

And within relational tables, anytime you would nest, you're pretty much creating a new relation and a new table for that.

You're doing so through a key, like through an ID. Right? Now a lot of times, your ORM that you're picking dictates the way you author that, and then the ORM handles all of the more complex bits of making sure that relation is performant. Right? But every single time you would typically nest the data in a structure, it makes sense to make that be another table. Or perhaps, like, sometimes you even have things that Yarn, like, roles. Right? Roles is not even nested. It's just an array of roles. But sometimes it makes sense for that roles to be a table itself as well. Now I'm not an expert in database design, so I think Wes and I should probably take some time to do some deep research and maybe do a whole episode on this stuff or at least a a hasty treat to give a little bit more type of an answer.

So you could think about it like this. Right? If you have 1 to 1, 1 to many, or many to many relationships, those types of things are important to set up correctly at the start. And how you think about that is really, you have to think about how this data is being stored and used.

So for instance, a user can have a session, and a session can only belong to 1 user. You log in. That's a session. That session belongs to 1 user. More users can access that session. That session cannot belong to more users. That's a one to 1 relationship.

Each time you query a user, that user's ID is able to pull in the session or the direct sessions. Hey. Actually, that's a one to many relationship. Right? Actually Yeah. Let me take that back. One to many. A user can have multiple sessions. You log in from your phone. You log in from your computer. You log in from your watch. That's 3 sessions. Okay? So one to many.

A syntax. We have a show. A show can have a guest. We can have many guests. A guest can be on many shows. That's a many to many relationship.

We had, let's say, Fred from ASTRA. We've had Fred on 3 times. Also, the show could have multiple guests on at once. So, you know, many to many. So you just have to think about how the data is used in that way, and then you set up your queries accordingly. Now like I said, I'm mostly working in ORMs, and the ORMs kind of dictate everything there. So you just have to think about how this data is being used and stored. And for the most part, yeah, you're creating more relations, each time you're having connected data. So let let's take some time to really strategize on DB design itself because besides indexes and and performance, things like that, you know, I'm I'm no expert myself given that the database I chose to use did not even have, like, schema safety for

most of my career. Yeah. My my only advice here is what I've been bitten on in the past, and I always Node will on the side of making another table instead of dumping a bunch of data into into a field or adding another category. If you find yourself adding, like, underscores, you know, maybe, like, we have a show and, but you may be, like, a show underscore guest.

No. That should be, like, that should be a real a related table. And even like like Scott said, I think one of the important parts he said Wes, anytime you're going to be nesting data, on the side of creating a new table. In fact, things like Prisma will just force you to make another table. You know? Like, you're like, oh, it's just an array of strings, you know, like a couple tags for a blog post. I'm just gonna put them in there. It's just a piece of JSON.

That becomes really hard to then query and filter, and it can also become a bit of our performance bottleneck if you need to be able to look for shows with a specific tag.

So on the side of doing more tables than you actually need, And I think an ORM makes these things a lot easier, at least for, like, 2 knuckleheads like Scott and I who Yes. Yes. Are not, like, geniuses Wes this type of stuff.

I know. I I come from a a firmly front end world. So Oh, yeah. I'm I'm certain don't take my opinion as expert opinion here. One thing that I found to be helpful for somebody like me is from the very start, whenever you create a new field, a created at and an updated at field, like, PEM is in there from the start Automatic. Feels like automatic. Right? And that's actually one thing I like about some CMSs. Like, pocket Bos always has that for you, and it you don't even have to think about it. So, like, if you can have those fields in there, it it helps down the line.

I I just think back to Wes I was in Vercel, I have, like, a business technology degree in, like, a a couple of the courses we had to, like like, database design, like, schema it out. We'd have to use, like, Microsoft Access, or Wes had to use some sort of, like, schema design thing. And it was hilarious because we would, like, turn in these, like, very obscure arrow diagrams, 1 to many, many to 1, all these things. And, like, I look back at it now, like, actually having done this stuff, and I was like, I had no idea what I was talking about. And, like, I would I passed it. You know? Like, I went to school for this stuff, and I don't think I I really knew what I was doing then. Yeah. I totally get that.

Next question we have here from Pnpm. Episode 796.

Do Wes need frameworks? The answer boys gave was great, but I wanna point out that front end masters, their whole platform is vanilla JS, HTML, and CSS, or at least it was 2 years ago. Not saying it's smart to build Amazon with vanilla, but I do believe it is possible. So I thought, yeah. Okay. Front end master's not using a framework. You know? They're not using React or whatever, but they're probably using, like, Rails or something and just doing all of it server side. So they probably still are. So I I tweeted at Yarn who owns Frontend Masters, and I was wrong there. He said, yeah, the only dependency we have is lit dash HTML 3 k for rendering package from the lit framework. We don't use lit, only the renderer, and then go with the same vanilla standard philosophy on the back end. The back end is in Go. So Yeah. Yeah. That's that's that's a good example of, yeah, you don't necessarily do need a framework. We we said our answer to that was, like, yeah. You probably do need a framework for most of this type of stuff, but, yeah, you you don't always need it. Like, I guess, like, a good chunk of my website also is framework less. You know? Just the the the viewing experience itself and the admin is built on React.

Yeah. For sure. Yeah. You don't need all that stuff to happen in the client side. You can have normal multi page application page load. But Node that we're gonna get up to page load rails on the back end. So I was I was, like, in the back end. So I was I was, like, in the go.

Yeah. But, like, Node server error to framework, though. You know? Like, that's just, like Yeah.

Straight up Pnpm, make your own thing. But at the end of the day It's actually Scott bad. You're building your own framework, I think. But I thought that was a great example. So thank you, John. Because you do need templates.

You do need to load the data and get it into the the client's account so you have a yeah. Right. Helpers. Yeah. Yeah. It's bespoke, but it, you know I don't know. That line is so blurred. Right? Yeah. Alright. Next question from Jace Munkie. Hi, guys. I've been doing front end dev for a long time. Once upon a time, I did a little bit of PHP and MySQL as well. I'd like to get some exposure to the back and full stack web development. So I thought about starting to try and build a basic login system for a web app. Any suggestions on which tech stack to use? Next. Js, Express, plus React? What kind of database? I wanna choose something that is a common stack these days to maximize the benefit to my employability.

I know some people out there will say, don't build your own auth solution, but the point of this is to be a learning exercise. Hey. I'm right there with you. I've built many auth system myself, and I like doing it. I did it as a learning experience myself. I've since then, like, adapted that code all kinds of ways, and I did 2 courses on it. So, those are free, by the way, level up dot video and Node auth fundamentals.

It's available for you if you get stuck or you want some strategic guidance or even if you want some full Node examples. I like this kind of thing, and I get where you're coming from.

So what tech stack to use? I think that's less important. If you're building off, that's more about the node side of things, the database side of things than it is the front end. And the front end side of things, that that can be whatever you know the most. But if you're looking for an opportunity to expand your horizons, I mean, you can't go wrong with picking React as your front end. Now React plus Express, Wes, you probably feel differently than I do on this. I would not do React plus Express. You you have a lot of docs on Express. Express works really well. No. I wouldn't either. I might pick something like Hano, which is a a more modern one.

Anything that gives you that routing, like Express, is gonna be fine. I don't know if you need to dive into Next. JS. If you're adding a lot of stuff in here, you right? You're doing database. You're doing auth. You're doing React. Adding in Next. Js, which is very specific, feels like too much for me. So I might keep it at just React, Deno, and then, you know, do your your auth stuff in Node with the the given node Yeah. Ecosystem.

I'm I'm very much on the the same page as you you. I think it's great that you wanna implement it yourself. I think people are way too quick to say use Clerk or use what's the other one? Sponsored this podcast for, like, 3 years. Why am I forgetting it?

Auth0.

Auth0 because that's really easy, and you get up and running. But, like, those things are get real expensive real quick when you sorta scale up, and those things also have every feature under the sun, which is you might need at some point, but nothing better than just learning how it all works by coding it up yourself, like Scott said. So I would pick if you're gonna do the back end, use Deno JS specifically because they have this concept of middleware, and what you'll be able to do is you'll be able to write a middleware that can protect. Maybe you wanna protect a couple of routes and maybe a couple endpoints. So you write a middleware that checks if the Wes coming in has a cookie. And if it does have that cookie, you do the auth to make sure that they have access to the resource that they're requesting. So Deno JS, very good for that. The reason why I say Hano JS is because you can very easily port those requests.

Those requests are based on web requests and web response. You can very easily port that to Next. Js or SvelteKit API or AWS serverless. You can port that to anything because the future of the web is not built on request and connect. That was sort of an older version of it. The new version of it is built on web requests, and being able to port that from one to another is very important.

Database wise, it honestly doesn't matter.

I don't know. Try SQLite. That would be kinda kinda neat. Or you'd try Drizzle with, MySQL or or Postgres. Postgres. And then on the front end, it doesn't matter because I would probably not while you're building this, don't muddy it with with React or a framework. Just try 2 things. 1st, try to protect a URL that should be protected with so forward slash admin.

And then second, try to protect a like, an API endpoint that returns some like, who the user is. You know? Return the user's email address forward slash me returns their email address and the their username.

And, if you can do those via a fetch request and a very literally a link that you click, then you will be able to to do it in any framework.

Yeah. And on the auth tip, we did do an episode three thirty six. I'll link that in the show notes of how to build your own auth, and it goes through high level of Mhmm.

Bos, cookies, cores. A lot of the times, people hold themselves back from learning how to build off because they get afraid of the security implications.

I mean, really, as long as you're assaulting and hashing your passwords, you're not storing things in plain text, you're using a secure means of, storing those cookies for your access tokens and refresh tokens. You just follow some basic rules here, and it's much more of a simple process than you might expect. And the simplicity in that process makes it a little bit less scary once you actually realize what's going on. Like you mentioned, the moment you offload your auth to another service, your auth is living on somebody else's computer. It's living on some other database. It's no longer within your other your same database. It's hard to take with you. It's hard to really own that. You're at the whims of some other service. What happens if that service goes down for a day? Your auth is pooched even if your site is up. So it's important to think about those things if you're if you wanna, you know, have a long lasting application.

Next question we have here from Jonathan Land.

Hey, y'all.

Long time first time. Love the new stuff you've been doing and the extras that CJ has been posting to YouTube. Yeah. CJ has been posting some fantastic YouTube videos, so certainly check that out on the Syntax YouTube channel. I wanna know if you ever plan on publishing video episodes to the podcast.

So, Jonathan, I think what he's referring to here is he might be saying you should post a video version of the podcast, which we do. It should be very clear to everyone. If you wanna watch the video podcast, the best way to do it is either watch on YouTube or go on Spotify. And Spotify is really cool because you can just open up the Spotify app. It'll show you a video, and then when you lock your phone, it'll just immediately cut over to audio.

He might also be asking here is just, like, using a RSS feed via another another, podcast feed will also have the video. And that is really tricky because the RSS feed essentially needs to be a a whole new feed. There is no way, at least this Wes I looked into it, there is no way to offer both audio and video via the same RSS feed, which is is really wild to me. I guess the podcast spec was was made many, many years ago before video was. And I've looked into podcasts that do offer video, and they always offer just, like, a second version of it, which is really frustrating. Because, like, the kinda sad thing is that is I just recommended you to proprietary viewing experiences, which do not use the podcast RSS feed. You know? Yeah. For real. But, certainly, if you do not know, we have been offering this in video for, I think, over a year now. So, certainly, check that on out. I I really like the Spotify experience because if you are doing dishes or something like that and we mention something that is visual, like the basketball that we talked about earlier, you can just quickly open up the app, take a look, and then close it on down, continue on your your day.

Yeah. The video version of the podcast, I feel like, is now the best version of the podcast, but we try to make it so that you don't lose anything on the audio experience as well. So, if you ever feel like we're drifting from that, let us know. But we we are trying to show more code now as much as possible. It's much easier to explain things Wes you have it right in front of you instead of, like, mouth Node it all. So yep.

Next question from Hoppelganger.

Passing JSX named props Vercel JSX children, which do you prefer, and does your choice change for different use cases? So what they're saying is, let's say you have a card component and you want to pass in the contents of that component.

One way to do it is to wrap another component inside of that card. So you have card, and then using it like an HTML element, you are inserting another element. Another version of that is you could pass a physical component as a prop into that component.

So what do you prefer? I almost always do the children approach. I'm gonna say a 100% of the time, I do the children approach, mostly just because, in my mind, that is the way it works.

You Node, you their your child is coming into your component, and the component is usually wrapping around it in some regard, whether that's functionality or display wise. So to have it physically be represented in that way, to me, makes more sense, and that's how I've really done it ever since JS long as I can remember.

Yeah. I will always say it depends.

So I will pass as a child if that is the child is the main content that goes into the body of the component.

Right? So if you have a blog post component and you are simply just passing the text that needs to go into the blog post component, then I would pass that as a child. However, it's it's kinda limited because you get 1. You know? You you only get 1, and that's really frustrating to me because so many other frameworks have this concept of slots where you can pass it. It reads so much nicer when you can pass it as a child component versus trying to shoehorn a component in as a prop. Because if your component also needs to pass props, it gets very hard to read very quickly. So I wish JSX had the concept of slots like SvelteKit does, because then you can just say, alright. Well, I have this component, and I need to pass it 3 other components. I need to pass it an icon. I need to pass it something that goes in the sidebar as, like, a promotion, and I need to pass it the main content for that component. If that's the case, it's really hard or or not possible to pass it as a child, and you need to individually separate those out into 3 different props of your your initial component. So I'll I'll say I don't like either. I don't like either of the solutions there. But if it's one thing, I'll use a child. If it's multiple, I'll pass them as props while secretly wishing that we had the concept of slots in JSX.

I'm gonna tell you, for your example of, like, a button with an icon Yeah. What I'll almost always do is have the button component itself pre include the icon component. So I'm not passing the icon component into the button, and the prop I'm passing into the button is a string of the icon name, which is, you know, validated via TypeScript or whatever. Let's say these are the properties that I got. Node them ahead of time, though. But, like,

for example, if you're using a third party component and you want to specify what the component is to click the play button,

that third party component doesn't know about your icons ahead of time. You wanna bring your own component for that type of thing. And if that's the key third party components, Wes. I only write first party components. Node. I I I am, that is actually a I would say that's a flaw of mine as a developer to say, I don't need your stinking third party components. Let me do it myself, and let me be ever so slightly worse.

What about the so, like, the

media controller syntax player passing the forward 30 seconds and and previous 30 seconds

components there. How how is that done? I'm following the the whims of the web components API. So for me, if I'm using something like that, I will follow their API. So you make the icon available as its own component. But then if you have your own button component with an icon in it, you wrap that icon into the button from the get go. And then if there's no string for the icon name, you don't show the icon at all. Therefore, it's a nice little API to say, okay. This has an icon, and it'll adjust accordingly. But if you wanna use that icon itself any other way on its own, you can certainly do that as well. Awesome. And, also, like, I think for, like like, tree shaking,

passing in is is a lot easier as well because, like Mhmm. If if you have 20,000 icons that are are possibly there, it's a little harder. I don't even know if it's possible if you were to tree shake the name of the icon, and then you'd need to dynamically require that icon.

You'd have to dynamically require it. Yeah. I you know what? It's funny that I I've I've been doing only, like, SVG sprites and stuff like that for all my icons lately, so they're all being loaded anyways.

Alright. That that was a great question. I like that a lot. Thanks so much for sending that on in.

Alright. That is the last question we have there. Please keep your questions coming. Go to syntax.fem and click on Paula cues in the nav. Send us your question. We love answering them on the show. Let's get into some sick picks.

Yeah. Sick picks. Hey. I'm gonna sick pick some earplugs. Now my my wife sleeps with the earplugs every night, and it's helped her sleep a lot.

And one of the things that JS, like you know, you have your classic foam that you, like, squish up and you fit in there. Or Yeah. You go high end and get some really fancy ones. I kind of, you know, bit the the link or not the LinkedIn. The Instagram

e. Oh, for the silicone ones?

The silicone loops. So they're just kind of nice little loop based silicone.

And you keep they come in a nice little case, earplugs, and you wear them every night instead of having to, you know, change them out. They they last forever, corny. They kinda they're kinda like AirPods without anything. They're $27.

So if you're comparing that to, like, the cost of a earplug that's like a little foam one, it's obviously much more expensive, but you use them forever. And, you know, she took these to a concert. She wears them to sleep. They're great, and they they work really well. And I think they're a little bit even they're pretty comfortable to keep in if you wanna sleep with them or anything like that. And they come in all kinds of colors. So at first, I thought it was a little goofy. It looks like a little like an actual earbud, but no audio. It's like, why would you need that? But in practice, I found these things to actually be pretty neat.

Awesome. If you do not wanna pay the, drop ship brother price that Scott did, you go to AliExpress and get them for $3.

I think these these are these are actually not drop shipped. I think they are probably 1 What's the what's the company? Loop.

L o u p e? L o o p.

L o o p. Okay. You're sorry. You're right. Somebody had messaged me about this that works at Shopify. Apparently, they were warp working with them. I do it's I we get the same ads. I get these ads all the time. The, you are, almost 40 ads, and so you're gonna need earplugs to sleep. Yeah.

Oh, man. I I falsely put the AirPods on, which I I I realize is awful. But I'm dying because I have I have 3 pairs of AirPods, and 2 or 3 of them at all times are missing one because they fall under the bed. And then what the saddest thing ever is the Roborock suck Wes up, and I threw it out before I even noticed. So now I'm, like, thinking, do I wanna pay for, like, a replacement, or do I get a new pair?

You let me tell you, Wes. The very first thing I do every single morning is I wake up and I say, alright. Where are my AirPods? That's the very first thing I do in the morning. I find the AirPods. I put them in the case. I need them charged if we're we're doing the show or whatever. So Yeah. Yeah. My biggest flaw in life is I just by multiples, and then I end up with by all of my multiples

being awful. Same with my socket sets. I have 3 Scott sets, and they're all missing sockets. Yeah. If I just had my life together a little bit better, I could have 1 with no missing sockets. But Hey. That's how it goes. Yes. I am going to sick pick the gecko's toes, a hose rack. And this is not for a hose. So we recently got a electric car, and we got the charger installed in the in the garage. And the the distance from where the charger is to plugging it into the car is about 2 and a half feet.

And the charger cord comes with a cord that is, I think, 20 feet long or 25 feet long. It's it's ridiculously long, which it makes sense. You can if you park in the driveway or you park on the other side of the garage, and you it reaches absolutely everywhere.

But it's just too much cable to have coiled up. And I coil it over top of the thing, but it gets in the way of the garage door. So I went on ESLint and thought, like, what are people doing to manage this? And a lot of people are using this really cheap little plastic hose rack called Gecko's Toes. Mhmm. We'll show a photo of it online, or you can Google it right now. It's essentially just a bunch of little slots where you can hang a hose in. And I bought 2 of them, and I just fed the charging cord up and down, up and down, up and down so that it's a kinda nice and tight and tidy, and I'm just gonna leave it in there in unless I actually need to pull it out all the way. So this is something that a lot of electric car owners are using to sorta organize their cables.

Yeah. So shameless plug, Wes mentioned in the middle of the show, but check us out on YouTube. Smash that subscribe button. Yeah. We would love if all of you would go to, youtube.comforward/atsyntaxfm and just, like, really pound that, subscribe button as hard as you can. That'd be great. We know how hard you press the button, so it would be cool to see if Wes can break it. Yeah. But, no, that's it. The youtube.com@syntaxfm.

Check it out. And that's all I got. Oh, that's a really good idea for I'm trying to think of the century hack week is coming up. I'm trying to think of, like, what would be a a good project to do, and I kinda wanna do something that's hardware related again.

But imagine imagine a subscribe button that tells you how hard you smashed it. Yes. Yes. This is a I'll show you something right right quick here.

I bought some hardware for I don't know if I'm gonna do this for the Hack Week project, but I wanna make this at some point. And it's just a MIDI slider, a single MIDI slider. And I'm me.

It's so tiny. You would just what I would do is keep it right here on my desk. And the plan for this midi slider is to write an application that is if I wanna raise my hand to talk while we're doing the podcast, I would just slightly move this up for, like and and a little hand would come up, and then I'd raise it higher and the hand would get higher. And then I Node it to the top, and the hand's like, you know, I wanna talk.

That's good. It should control a hand in my office. Like, what if we both had 1, and we we connected it to them to the back of the monitor? And then when when one of us wanted to talk, you could just scroll it up, and it would come up behind my monitor. Oh my god.

Yes. Oh, that's hilarious.

It's not a bad idea.

I know. I actually built the part of it that works in terms of, like I have the the WebSocket in the, the whole thing going already with a physical slider in the browser, and it shows a little hand coming up. So all I have to do is connect it to the MIDI API, and it it should be good to go.

That's good. That maybe that'd be a good show. It's just us talking about our ideas and then have an aftershow of what we did. My other one was I hook up the the Nerf gun so that if I I have a uncaught exception, it shoots a bullet at me.

Because it's if there's switches in it, it's just 2 switches.

Train yourself to, like, be really, be on edge all the time. That's gonna make you stressed out. Oh, yeah. Oh, yeah. I think that'd be funny, though. Bracing.

Alright. Well, stay tuned for Ridiculousness.

Thanks, everybody.