TypeScript, Branded Types, Streaming vs Polling + More

Welcome to Syntax today. We've got a potluck for you today, which is you submit the questions. We bring the answers. We got some really good questions today around, is having TypeScript errors okay? What about TypeScript branded types? Is that an interesting pattern or not? I, me, Wes, was wrong about QA.

Some interesting submissions from people who work at banks and and how QA works with them, streaming responses versus polling, and finally, storing access cookies and authentication in a cookie, or should that go in the server database? Really good questions. If you got a question yourself, go to syntax.fm.

Click on the potluck queues button in the nav and submit your question. We'll answer it on a future episode of Syntax.

Let's get into it.

How you doing today, Scott?

Oh, I'm doing super good, man. Just hanging out. Kids had fall breaks, and they were were home all for the past maybe week or so. And we did a lot of fun stuff because, we were supposed to be on vacation, and that had to get canceled. So, you know, we just did a lot of cool stuff. Yeah. I saw you went on a a hike.

I saw you went on a hike, copycat. You're I'm not much of a hiker, but my kids have my kids go on, like, these, like, forest days at school, and they've been been absolutely loving it. They're like, can we go on a hike? And I was like, sure. I can hike.

Yeah. It's a lot of work. Yeah. Colorado, believe it or not, has, like, 10,000,000,000 hikes. So we just drove into Breckenridge and found 1 that was walkable from the downtown. But, yeah, you're hiking up a mountain and yeah. Yeah. Our our our kids like it, but I think they get bored after, like, the the 2, 3 hour mark. They're like, alright. Give me off this thing. Yeah. We didn't go that long. We went, like, an hour and a half or 2 hours, something like that. Yeah. It's just long enough. Lots of waterfalls in Hamilton, so they're pretty excited about that. Oh, that's dope. That's the best kind. Yes. Hey, Wes. If you're seeing a lot of waterfalls in your code that are potentially slowing down your site, right, you maybe you didn't you didn't realize that you are loading things in a certain way and, well, you have a slow route on your site. Well, you can discover that, fix it, find it, and, make it better, make it faster, make it less miserable for your customers with century@century.io.

The performance tracking tools are 1 of my favorite things in the entire world because when we first launched the syntax site, man, there were just some little things here and there that we did not see. And then when you start to get the scores in Yeah.

Yeah. This particular route is slow, then you could say, oh, let me let me dive into why that might be. Oh, here's why. We're loading a giant transcript on everybody even if they're not visiting the transcript page. Let's fix that. Right? So head on over to century.ioforward/syntax.

Sign up and get 2 months for free. Use the coupon code at tasty treat. Alright. Now let's get into the details. You should go chasing waterfalls, and you should fix them with Scentree. Oh, yeah.

Perfect way. But first question we got here from Brad. What are the limitations of SvelteKit? Are there certain applications it wouldn't be good for? I thought this was kinda interesting.

What do you think, Scott?

As somebody who ships everything with SvelteKit, I'm gonna say no. There are no limitations. No. There's none. I you know what? I honestly don't even know because, what, it can do static sites well. It can do node based sites well. It can, you know, deploy to to workers. It can deploy to serverless. It can do all that very well.

You can have, you know, an API based site instead of using their their RPC sort of system with the form actions.

Mhmm.

Man, I'm having a hard time. I I I've deployed apps with SvelteKit using Tori.

I've deployed even just this is this is crazy, but I wanted to do a like, just a a Cloudflare worker. And it was easier for me to just do it in SvelteKit because I wanted a small UI attached to it. Like, I found myself writing HTML templates and strings, and I was like, you know what? I'll just bump this ESLint the SvelteKit and do it that way. So are there limitations? Probably limitations somewhere, but, like, man, I I've built everything with this. And,

I don't know. It's it's it it holds up. That's all I can say. Maybe, like like, what about the, like, partial hydration or, like, the server islands point? Because with SvelteKit, you're kinda going all in, and the whole website needs to be rehydrated.

But if that's the case where you want certain parts of your website so the idea behind server islands is that you you server render everything static, and then you opt in to pieces of the application that are are going to be client rendered, and and they're gonna be dynamic. So I was on a panel about this at the conference last week, and I came up with the stupid idea of people were asking, like, how do I transition from 100% SPA to, like, an Astro Wes you sort of opt in to the client kind of thing, you know, like, the island approach. And I was like, well, you can start off with a 100 a 1000 islands, and you could just start syncing those islands. Meaning, you can just kinda piecemeal component by component, move them off of the client onto the server.

So the syncing islands approach, you heard it here first. That's my, my invention there. Yeah. I could get into some of my gripes about SvelteKit if you wanna hear that. Yeah. That's what I thought. Like, I think you can build anything with anything.

Yes. There probably are situations where you get into very large applications where you go, it would be really nice to have partial prerendering or a lot of this, like, kind of odd stuff that, like, Dex. Js has a lot of this really advanced stuff, and most people probably don't need that. But if you're getting into really, really heavy applications, it sure is nice to have it. Yeah. You mean, like, partial prerendering JS just, like, certain templates Yarn par partially prerendered? Is that what it does? Yeah. Yeah. Like, not not page based. Based. Yeah. Almost always my gripe with every framework is that I don't wanna do data loading at a page level Oh my god. Because my data is is associated with a component.

Figure it out. You know? I wanna fetch the data in the component. I wanna take care of the data in the component. Or if it is a page level thing, I can pass it in, but that's often my gripe.

Yeah. I would say if we're getting into gripes about SvelteKit, those are my gripes.

Node, data loading is tied to routes. I would really prefer if it wasn't tied to routes. 2, the islands architecture, I would prefer to be able to do partial rehydration and islands and all those things, out of the box. Those are my my 2 biggest gripes with it. Other than that, it pretty much handles everything I Node it to handle. I still want and I think you said this is coming. I still want to be to do multiple components per file.

Yes. So all the time here. I'll find myself in a component or a page where I'm like, I'm looping I'm looping over this, and inside the loop, I want it to be its own component.

But as soon as I have to move it to a separate file, then I gotta redeclare all the the props and export everything. It's like this whole thing whenever you make a new component. And I was like, I just want to have a separate template thing. So that's coming. What's that called? By the time that you listen to this episode,

fans of syntax and listeners dear listeners, by the time you listen to this episode, this will be released. It's in Svelte 5. It's called snippets.

And, basically, you're just defining, like, a function essentially in a in a template tag, and you can pass variables into it. You can type it all. It can all be type safe. So yeah. It's called a snippet in Svelte 5. And, that's a good way to do that Wes you might not want to have a a whole other component existing outside of your component. But also maybe you wanna have something that you might refactor later and you're just hacking together. So yeah. Yeah. Yeah. Just quickly.

It's here. Sick. Alright. Next question from Squinkle Butt.

What are your thoughts on branded types in TypeScript? They seem nice for things like record IDs and email addresses, but there's a fair bit of code setting them up. Is it worth it? So the problem that this is trying to solve is if if your TypeScript representing your data is not specific enough Mhmm.

I Do do you want me to ex take a stab at explaining it? You take a stab at explaining it because I don't necessarily I'm gonna say before you even get to it, I don't see the the need for this. But Mhmm. Alright. So at a very basic level, let's say you have a function that takes in a an ID, you know, generate display user, and it takes in an ID. Right? And that ID is going to be a string. Right? You could literally pass it any string, and TypeScript gonna say, looks good. That's a string. You know? And he's like, no. I I kinda want it to be a user ID. It's also great for documentation where your function takes in an ID, but then you brand it as a user ID. Like, oh, okay. I know I have to pass in a user ID and not some other type of ID in this case. So the idea with branding is that you can sort of take a a simple type, like a string, and extend it, so that it will be named something different. Another example I have is, latitude and longitude.

When you are defining a 2 pull in TypeScript, a lat long 2 pull, is simply going to be an array with number number. Right? Mhmm.

And for me, I think, oh, that that's that's okay. But I've I've often mixed up lat long with long lat because some mapping uses long then lat and some uses the opposite.

Totally. So a a great use case for that is to simply brand it, and have have a name on there. Because when you're filling out the tuple, it will not just say number number. It will say latitude, longitude. And in that case, I'm branding a number as longitude, and then I can have a tuple with that spot in it. So, essentially, it's still just a number, but it has a type of longitude.

It's a type for your type.

Yes. Exactly. So Yeah. I I don't have a ton of use cases for it. It's more getting into, like, the validation realm of things Wes you're like, and, usually, the way that it works is you put, like, an underscore underscore brand property on your object. Almost every time that I reach for them, then you run into issues where you are just passing a straight up number, and it says, hey. Yes. This is a number, not a longitude that's been branded. So then you gotta brand it properly. Cast it. You're doing all this annoying, like, jumping around. So I don't know. I use them every now and then, but they can be nice for record IDs like you said. But I I would say probably not worth it unless you're explicitly having a problem that that would fix.

Yeah. And to be clear for the audience, the the brand generic is something you make Vercel, so we've included that in the in the show notes what that looks like. It's just a TypeScript with a a couple of generics in there. But, you know yeah. To me, it just feels like extra work for what could be, pain down the line even if it is giving you clarity.

I I think it might be different for maybe library authors than for, like, individual app code, but who knows? I I don't know. To me, it just seems like overkill, but, you know, everything seems like overkill until you have the need for it. So Exactly.

Yeah. People are not just making stuff up because they they want to. It's these are problems that they've actually run into.

So in my opinion, it's always good to learn these things and then just have them in your noggin so that when the problem comes around, you go, lessons. Scott talked about branding. Okay. We need to do that. Yeah. Next question we have here from Ruby Dev, long time listener, first time caller. Wes, you've recently mentioned never using a queue in applications. So it's got me thinking, how do you handle sending email in your projects? If you're using SMTP, have you never run into performance issues? I've come from a more classic MVP, batteries included, background. So offloading potentially slow tasks like SMTP email and sending that to a background worker rather than tying up the main process is just a convention.

In Node Express, Deno, etcetera, like the JavaScript stack, would a fire and forget a promise that sends an email be more or less a poor man's queue? What's your take on this? So, yeah, this is perfect example of in my application, when you buy a course, I send that I do a whole bunch of stuff. Right? You you create it in the database. You you validate the data. You you charge the credit Yarn. And part of that process is sending an email to that user that here is your actual process. And the performance issue that you could run into here is that if you if your user clicks buy and they're sitting around waiting for the all of that to happen, sending an email could be another 500 milliseconds or or whatever for them to sort of sit around and wait for that type of thing. Right? So what most people do is they'll simply just throw that in a queue, and then another process will pick that up in the queue and say, oh, I've got some emails to send, and they'll send the email pretty quickly. That's why sometimes when you, like, do a password reset, sometimes it comes immediately. Sometimes it comes, like, 20 seconds later. That's because it's they're they're processing their queue, and maybe they can't possibly keep up for it. So what do I do? I do I do the poor man's queue, which I'll explain has just bit me a couple weeks ago. So the poor man's queue is fire and forget, meaning that Yeah. I will simply just fire off the send email function. I will not await it, but I will tag a dot catch on the end. And what that does is I can send the response back to the user while that's still happening in the background. That that works on Node. Js.

It works on some serverless platforms where you can still do work after you've sent the response. Actually, I saw I think Laravel announced this the other day as well where, yeah, you can fire off a function, and it will keep running even after you've sent the the response to your user.

And that that's worked great for me for probably 10 years because I I still know if something's something's happening because the catch will run and and catch my error, and I'll see it in my century.

But I ran into a problem the other day where my email, provider, which is, Postmark, been a big fan of Postmark.

They had an SSL certificate expire, and they were down for 12 hours.

And what happened was for 12 hours, the send email was sending, but their SSL certificate was down so that my my requests were were being blocked.

And in my case, I didn't have a queue. In most cases, the queue would realize, oh, that didn't send. Let me try again. Let me try again. And right. And then the the as soon as it comes back online, then the queue would just keep on sending. In my case, I had 12 hours worth of emails that simply did not send. Right? And I could I could see it. There are people trying to reset their password 11 times because I'm not getting the email. Right? So I had to go go through and look at what emails had tried to be sent or or what people had bought something in the last, 12 hours and manually trigger those to send. Had I had a queue set up, that would have not been an issue for me. So, certainly, a poor man's queue will get you so far, but III need to get a queue now that I'm I hit that actual issue.

Yeah. I don't think I've ever had enough emails being sent out where this has been a problem I need to worry about because I I guess I'm I'm not working on anything that has, like, a crazy amount of current concurrent users trying to create accounts. Right? Even with LevelUp, you would have, I don't know, how many people creating an account at once. It never got anywhere where it was It's not even that

even even if you're getting, like, pnpm every 30 minutes, that would still be 24 people that didn't get their emails because you we're just assuming the SMT service will be up. Yeah. You're right. Right? Yeah. And in that case, you cannot assume that your your third party infrastructure will be up even if you're up.

Yeah. That's, I mean, that's a good point. You know, 1 thing that it further makes me miss meteor here is that there used to be, like, a really good meteor automatic, like, queue system where it was just, like, you drop in a plug in and now you've got a queue. Add to queue or you like, you had to do 0 work to get this queue and it persisted to the database.

I miss that. I miss that kind of thing because that then it it was easy to do this stuff. And maybe it is anyways, and I'm just, being ignorant. But yeah. Yeah. I I think it is is relatively easy to get up and running. I will implement it and come back to you and explain my process. Let's do it. Let's do it. On it. Yeah. I would love that. Thank you.

Next 1 is from QA Lava.

Good day, legends. Not a question.

I just don't have Twitter, so I couldn't tweet you about this. Just listened to the potluck where you discussed QAs and was a bit surprised with Wes answer. And I think it might be reflected of his lack of experience working with dev team. Put this in here because it is. Yes. I love it. This is the lack of experience

episode of, Syntax, Wes's lack of experience.

Well, mine as well. Yes. Not a stab. Wes is obviously an incredible dev. We all just have different paths. That's that's correct. A ESLint a decent QA team is invaluable and has a very different role to unit integration e to e Wes. I worked at a few companies with dedicated QA teams, and their role is much more than poking around your work and seeing if it's ready. They will triage issues, provide, repro steps, actively work with you to check changes, work with stakeholders, and ultimately use the app in a way automated Wes could never.

If your Wes can replace your QAs, then you have shit QAs.

The automated test approach also assumes devs are given time to write good tests and are skilled enough to write high quality Wes. Both of which I've seen at maybe 50% of the places I've worked. Not a dig. Love your work. Cheers. Hey. I agree with you QA, Lava.

Not because I've worked GitHub, better QA teams, but I I do understand that, you know, these folks are are valuable for a reason, and it's not just to make your your dev's life harder, especially at higher stakes organizations. Yes. I think that's the big thing. You Node, a lot of times, Wes, you know, we work in JavaScript. And and, honestly, this helps keep Sanity, to be a a popular tool, and we just huck huck stuff up. Right? We just we just huck it over the warp, and we'll see if it works and then checks our errors when, with our Century. And by all means, do that because we want, you to keep subscribing to Century. But I do think, QA, I do think it's important. So thank you for this perspective here. I

heard from a lot of people after this episode, which I thought was really good. Specifically, I heard from 1 guy who works at a bank, and he said, we certainly have a huge QA team.

And it was mostly that. This stuff is extremely high stakes.

We need somebody to go absolutely through it all, and they have their own processes to make sure everything gets gets hit and whatnot. So they are invaluable to our team. And and like this thing said as well is that they can reproduce it. You Node, like, if a user is saying something is not working, a QA I never even thought about this, but a QA team can actually sort of guard the developers and say, is this an issue? Where where is it happening? How is it happening? In what in what circumstance? You know? And they can bring all of that to the developer and say, here's a nice tidy bug that we filed. Here's all the issues that's going on. So that was really interesting to hear. And then I at the conference last week, I talked to somebody else from a very large bank, and they said they are trying to automate a lot more of their tests because they find they said Wes have 40,000 pages, and they will go through several thousands of them. And if there's a bug on every page, like it's an app wide bug, they will log it for every single page, and then they then you have to go back and forth with them. And that seems like a like a crappy QA team, like this question said, you know, where it's just making more busywork. And now the developer says, like, I hate it because I have to I have all this, like, back and forth. I have to talk to them. We have to have meetings.

And, like, I just wanna get back to actually building stuff, but now I have this, like, other client, which JS, the QA team. So it's certainly things. He's he's like, I wanna automate a lot of it. I think that stuff should be automated, but your QA team should be there to to serve you and to help you, which is what I've been learning. Quite a few people reached out, and I thought that was so I love about this podcast. You get to hear what everybody actually does.

Yeah. And respectful too, man.

QA lover. Shout out to, not just being a jerk about this and being like, hey. Wes is wrong, but he's great anyway. So, I love that.

That's the best way to tell us what we're wrong is to tell us how great we are while you're telling us we're wrong. Yeah. Next question from Nathan Noller. You should do a show on invoker commands. They're not quite spec yet, but they are awesome, and there's a polyfill. You can declaratively wire together buttons and dialogue elements as well as a number of others with Node. Js. So that whole word comes up quite a bit when we're on the show JS declarative.

And and what that means is that, like, writing HTML is declarative.

When you when you are associating a label with an input simply just by writing the HTML that's declarative. Right? React is very declarative of looping over and and displaying elements rather than, like, waiting for events. So Keith Krickel is the author of them and is really interesting person too. Yes. Highly recommend you follow Keith on Twitter. Very good. You'll also see him in, like, every GitHub thread about every web standards. Yes. I know. Yeah. A web Deno who've crossed the divide into implementing features and and whatever. So invokers, I don't think I've seen this yet, so I'm gonna throw it over to you, Scott, because you have dove into it.

Yeah. I actually during my last Denver script, I, I did a bit on invokers because I think they're really super cool.

And, like, this person says, they're not here yet, and the polyfill JS is really it's useful, but it's not that useful because it doesn't support most of the proposed invokers.

So you what you can think about when you think about invokers is an attribute to trigger some sort of an event.

So you might put on a button a invoker, which is the command. It's the command attribute. And then you have a command 4 attribute, which is an ID of the thing. So let's say you had a popover.

You could have a button with command 4 and I ID to the popover itself, and then the command is a string of 1 of the following, toggle pop over, hide pop over, show pop over. There's also show modal or close, which work for dialogue elements.

So, basically, you're sidestepping a JavaScript click event or anything and putting it directly as an attribute. Now where this gets cool, Wes, is that it's not just those. The other proposed ones are for, like, the details element, toggle open close, the dialogue, toggle cancel, the select, show picker, input.

Yeah. Input show picker is 1 that I would love because I just had the situation the other day where I'm trying to show the picker in Safari, and for some reason, Bos Safari does not support that method.

Now there's even other ones like an input type number.

You could invoke the command of step up or step down or for video and audio elements. The video and audio, we gotta have this.

Right. So you could build a custom play button for a video component without JavaScript by having a command play,

command 4 to test the video.

Yes. So, basically, this is so much sense. Yes. It's like click events in HTML using this command in command 4.

And there's a handful of proposed ones. I posted a link to, Open UI's blog post on invokers, their explainer. It's well worth your read.

Mhmm. This could save a lot of JavaScript, but it could just make things way more clear. It's essentially yeah. It's like adding an ESLint on click, and firing some JavaScript like you would in React or something. Got it.

I've I've, like, written this many times with video and audio elements where I'll just have, like, a data dash action equals. Yes. And then I'll just put the, like, play, pause, toggle, whatever in there, and then I'll listen for anything that has a data dash action.

And then I'll I'll I'll run that method programmatically from the data attribute. This is great. I I wonder. The the only thing that I'm like, JS there's no, like, arguments. Right? So, like, there's not 1 for speed up or speed down because people are gonna say, well, what if I want to speed it up by 10%? Yeah. You know? Or what if I wanna run this function after a certain amount of money or a certain amount of time? That's probably where you you start dipping into JavaScript, but I think that would be also nice to have, like, a command dash argument.

I don't know. But but before you know it, we're Yes. We're we're recreating JavaScript in declarative HTML.

Yeah. But, yeah, Volker's well worth your time. Give it a give it a read.

Like I said, I talked about this at Denver TypeScript, and that talk is online if you wanna see that as a part of my you you might need less JavaScript than you think talk. So, yeah, cool stuff. I'm excited for these. Cool. Wow. I'm into that. Oh, and I should say the polyfill, it supports just the, pop Vercel dialogue ones or at least a couple of the dialogue ones. It doesn't support any of the other ones just yet.

So you can use the polyfill if you wanna try that out. Nice and neat. So next 1 from Ryan. Hey, guys. You recently released a 2 parter sharing a number of apps and tools that you use. Some of them were pretty cool on the list. I'm going to download none of them.

Maybe I'm just paranoid, but I've gotten to the point where I download almost nothing to my computer.

I used to be the type who would crawl all sorts of these lists to fill my hard drive with fun and interesting useful tools, but I've become much more concerned about security and privacy lately, especially with the advent of AI. That is smart of you, Ryan. I no longer feel that it's worth it to download an app which might be kind of cool but also might be sending my keystrokes, passwords, bank account info, and other Scott confidential information to their servers without my knowledge.

Is this something to worry about? Do you do any kind of vetting or sandboxing when trying these new apps? Yeah. I I think the only way you can really know what exactly is going in and out of an app with ease is by using Little Snitch, which is an application that, anybody who's pirated anything at their life would have seen Little Snitch. But Little Snitch is basically an application that lets you know any request going out from any application.

And by default, when you turn it on, it, like, pops up a dialogue any single time somebody's trying to phone home. So if an application is trying to phone home for whatever reason, little snitch will pop up and say, hey. This app is trying to connect to this server. Do you, like, approve of this message? And allows you to say yes or no. Man, little snitch has gotten a glow up. I haven't been on this website in a little bit, but, man, new version of little snitch looking looking,

price. They had they had, like, a a mini snitch or something like that a a little while ago. I installed it for quite a while because, yeah, there's something about these apps that JS is kinda scary. Right? Like, especially with a lot of my I I talk a lot about all these keyboard, and I have several apps that will respond to keyboard input globally. Like, you have to go into your macOS settings and give it full access to everything. So you essentially just install the key logger, and then, like, it it's it's kinda scary. Right? And I will often open up proxy man and see what an app is doing as Wes, But there's this, like, delicate balance between like, using a little sensor or even macOS is is pretty good at above it. They're they're so aggressive that if you do wanna give something access to your screen recording or whatever, it's actually kind of hard. Right? You gotta find out where it is, and you gotta turn it on and restart the application.

But if there's too many pop ups, then it's it's so annoying, right, especially to regular users.

So I don't know what the solution is here. It's the same thing with node modules other than lots of people have eyes on this type of stuff, and you have to have a bit of a bit of faith at some point that these people are not doing awful stuff, because there's there's lots of like, I think this is a huge vouch for the web because the web is sandboxed by default. Right? Mhmm. Like, often, Wes is like this as well. I I'll see these TikToks all the time where people are like, don't scan a QR code because when you scan a QR code, it's gonna download all your information and all your contacts will be sending. And I was just like, it that stuff kills me because I'm like, unless there JS a major, major vulnerability, we would have heard about it. And, also, people are not trying to steal your contacts if they have a major vulnerability. They're selling it to countries who are in war, for 1,000,000 of dollars.

And there that also like, technically, I understand.

No. You the web doesn't work like that. You can't just go to a website, and it just gobbles up all of your photos.

You have to explicitly give action to those TypeScript thing. Now that's that's where, like, fishing and whatever comes in Wes you're trying to trick people.

But the the web, especially a URL, the URL bar is a major security thing. So I agree with you JS I prefer them to be on the web.

And that's why I I wish that the progressive web app was a little bit better because often I'll just download the the Electron version of an app because I just want the icon, and I want it to be on my desktop. But if they're shipping Electron app, they can do whatever they want to to that build.

And, it's it's kinda scary. So I agree. Yeah.

Yeah. I I think this is is smart of you to to vet your stuff. I I think we're all probably being a little unnecessarily reckless, with many of these things. So little snitch if you want to, have an eye on that stuff and if you want to install some of these and see what's going on. And if you wanna just, not install it, that's probably a decent idea as Wes. As long as, you know, I like, what what am I give it? Like, I I am ignoring security concerns myself, so that way I can, click 1 button instead of click 2 buttons to do something. So it's like,

yeah. Yeah. That's it's also, like that's how if if if we're annoyed by this stuff, there's no chance that regular users are gonna want to use this type of stuff. Regular users Yeah. Unfortunately, don't care as much as we do, and we're not gonna implement such aggressive things into it. That's that's why, like, everyone likes to hate on Apple, but they I feel like they mostly care about our privacy. I know that people are probably saying, well, they they care about, selling your own ads. They wanna be in in charge, and Apple's the worst. And, yes, I agree. There's I'm sure there's there's cases there, but I feel like, mostly, there's there's some use cases where, Apple is is protecting our privacy. I just wish they made it a bit easier. Same with, like, have you ever you know, when an app access it's like, can I have access to all your photos? Yeah. And I go, no. And it's like, okay. Well, here's this pain in the ass. Like, wait. Now you have to opt in to every photo. And she's like, can I just can you just show me my photos, and I'll I'll click them? I don't wanna have to, like, select them, and then you add them to my list of allowed photos, and then I have to select them again.

Just don't let somebody upload all of my photos. How about that? That UI specifically

makes me almost always check. Yeah. You can have access to all my photos because it is I I almost always wanna be optimistic with it. And by, like, a weekend, I'm like, I've had it with this shit. You know? It's like

Wes obnoxious.

Question from James from London, UK. I love the show. I'm looking at adding a checkout flow to my site, and I want to know what kinds of things to be aware of when going in. I listened to episode 6. Oh, that was a long time ago, accepting money on the Internet. It was super interesting to hear the differences between Stripe, PayPal, and Braintree.

I'm interested, how things have saw have evolved in 7 years. Is PayPal still difficult to work with? Is Stripe still the best? Do SDKs and APIs have the same flow? Would love you to revisit that episode. Yes. So I actually just rebuilt my whole checkout, and I did this this whole song and dance.

And PayPal is getting better, and Stripe is getting worse.

PayPal is still awful in in many, many ways, but their stuff is getting significantly better. They have, like, gone on, like, a gut, basically, deprecating all. 1 of my my pains with PayPal was that you search something and you find, like, this old outdated documentation or you find this old PayPal thing that doesn't work anymore and nothing works. So they're basically just gutting it all, and there's gonna be just a several ways, a couple ways to go about it. A lot of these companies as well are trying to push you in the direction of just, like, let just redirect your user to us, and we'll do it all. Right? So that's a lot of people only support Stripe because you can use Stripe's checkout, and then you don't have to implement anything in their thing. But for me, I want Stripe, but I also want PayPal. As much as I hate it, lots of people still use it, especially outside of the US.

So I ended up going with Stripe Elements, which is their, like, embedded Vercel.

And then it's actually gotten quite a bit better in over the times. You can style it pretty much any way you want. I integrated PayPal in it to make it look almost native.

And then the benefit of that is you also get, like, Apple Pay and and Google Wallet and Yeah. Which AliPay works. Yeah. It just just works. So I probably would still tell you go the route of Stripe Stripe Elements, because almost always Wes you go, like, the Stripe checkout or use some service, you're gonna hit some annoying thing like, I can't do country based coupon codes. I can't do this this this checkout logic that is specific to to my use case. Yeah. III

do tend to really like it when I'm on a website and they end up using the the Stripe checkout just because you just text my phone and then my payment information's all there, like, as a purchaser. But as an implementer, I had to go with Braintree in the past because it was allowed you to support PayPal and credit card within, like, the same interface. But, man, Braintree was just so rotten to work with. They got they got mad at me after that episode because yeah. It Wes just hard to work with, and it still is. So I I don't know. Yeah. I I think what you see a lot now is, like, services on top of these things even Wes you have, like, revenue Scott, you have lemon squeezy, you have Yeah. Man, I feel like there's a few of them. And I I'm sure those are all good. It depends on what you need, But everybody who steps in between you and the payment processor is going to take a chunk.

So if you need PayPal, you're probably gonna be still getting a little bit more custom with it. If you don't, man, just go Stripe. And What kills me is Stripe

supports PayPal as a checkout option, but only in the UK.

Yeah. And, like, I have emails going back, like, 6 years with some of the people that work at Stripe being like, can I please you'd please just enable PayPal as a payment option? You know? I wanna I would love to just go away from this whole second implementation of the code base Yes. Which is is PayPal's implementation.

And the also, the problem with Stripe that I was having is that there's so many different ways to do things.

And every time I had an issue, I would jump into their Discord, and they'd be like, well, you could instead of doing it on the client, you could do it on the server first, and they just break my entire flow. Yeah. Yeah. Or or both Stripe and PayPal. I'm using a dialogue, but Stripe and PayPal often will have to put up their own dialogue because when you're in in Europe, they have this, like, 3 d Secure, which is you'll have to, like, input your banking password or or send a text message and and put the code in. So when that happens, you can either redirect them to another URL. But if you wanna keep them on the page, they will try to embed an Iframe to the bank.

But then that thing goes underneath the dialogue because the way that dialogue works with top layer, you can't go over top of a dialogue with z index. Right? It's it's impossible. It's a top layer. Yeah. Stripe and PayPal need to both move to dialogue Bos, and, I've had an issue open on both of theirs with for 6 months. And every couple weeks, some poor soul comes in and goes but it's also made me rethink, like, are we overusing dialogue boxes just because it's easy to pop something up?

Yeah. Right. Yeah. That may be yes.

Yeah. For sure. Cool. Next 1 from Anan. Christmas gift episode this year, please. I put it on the calendar. So, yes, we will do a gift episode, and we will have it out at the end of November so you have some time.

Beautiful. I'm looking forward to that. It's been a while.

Me too.

I can has code says, I noticed some cloud service providers allow for the creation of resources that take a few minutes. So for example, you create a new box on DigitalOcean, and it says, like, it's procuring it. It's setting it up. It's installing. Right? Sometimes takes a couple minutes. While the process is in queue, the user interface to play some information about the resources being created. In some cases, there are multiple steps along the way to give the user feedback on on each how each 1 is complete. Often, this allows the user to navigate away from the page and back to check on progress or continue when there's a notification. Is this just long pulling WebSocket streams, or is there something else involved? Much appreciated. Yeah. So there's several ways that this can be done. When you click a button to create a resource, the resource will send back, I'm working on it. Right? And that resource of I'm working on it can be could be a stream. Like you said, server sent events are probably the most common implementation for streaming from the back end, and this will allow you to send as you get updates on the server, you can send data to the client as it's going.

WebSockets is another 1 that'll give you sort of 2 way. And then the third 1 is just long polling, meaning that every 10 seconds, you pull the back end and say, hey. How's the server going? And almost I think in most cases, it's just gonna be long polling because with streaming or with WebSockets, you gotta make that connection. And if somebody closes the tab and then opens it up again, you gotta make that whole connection again anyway.

And, also, if you have it in open in multiple tabs, if you if you open it close it on your thing, open it in in your your iPhone, there's all these, like, weird use cases where it's probably not worth streaming that data when it's so low stakes. Right? Chat application, AI response. Yeah. That's probably a good use case for streaming WebSockets.

But simply just checking how something is doing, you simply can just ping ping ping every 10, 15 seconds, and then the server will say, yeah. Still working on it. Right now, I am combing the hair of your, Drupal machine so we can get that thing ready.

Top form, Wes.

Good to be the combing the hair. Yeah. It's hilarious.

Sick. Nice answer.

Next 1 from John.

Is it safe to store access and refresh tokens, etcetera, in a cookie? I'd always thought that the recommended pattern was to store that information in some sort of DB store like Redis with a session ID and then return the session ID to the browser and store it in a cookie, which presents some service design challenges. Thoughts on this? Thanks. Love the show.

So, yeah, there's a lot of strategies for this. Sometimes you just do put a session ID in a cookie, but a session ID isn't, in my mind, any more inherently secure than putting the access and refresh tokens in a cookie because both of them give you access.

So like a session ID token is really just saying you have initiated or started a session.

That session is validated, verified in the database.

And if that session is needing to be refreshed, then you use the refresh token to refresh that session. So you're wondering if this is secure to store them in a cookie.

The answer is Wes. But the right way to store them in a cookie if you want to be the most secure with it. Now granted, there's caveats to this where you can store these in normal cookies in certain ways and have it be fine JS long as you have proper, like, course protection and stuff. But if you wanna be the most secure here, which by all means, I think you probably do. Right? The way you want to store any of these cookies, whether it's an access or refresh token or anything, is with a secure same site HTTP only cookie.

HTTP only means that the client JavaScript cannot access this token. That means, no extensions, no scripts, nothing can access this token from the client. Right? So, yeah, you can pop it open in in dev tools and see that it exists. It's saved in the ESLint, but you cannot access it with JavaScript.

2, secure. Secure means that this cookie will only be sent inside of a secure context.

So not HTTPS.

It's not sending the cookie. 3, same site. Same site as an attribute that allows the cookie to be sent, to the application if the requested origin is from the same domain.

So, that can work for subdomains too if you have an API Scott, whatever.

So if you have those 3 things inside of your cookie being stored, it's really, you know, you can store access to refresh tokens. Right? Because the client has no access to get to those. And the the attack vectors are are limited in that regard. Right? Because that's really what you have to worry about. So they're being sent over HTTPS.

They're only being sent to the same Vercel, and they're not being able to access in the client. That's a a pretty common way to do this. And, Wes, I've been diving into a lot of different auth patterns lately. I'm I'm, like, writing a JWT auth for my drop in. And it it's all kinda there's all kinda wild different auth patterns out there. I always did it this way Wes you have an access token and a refresh token saved in HTTP cookie or potentially

just a session ID. But, yeah, I'm I'm getting into more different things now. So yeah. Maybe we should do it do a whole show on it. I think the only, like, scary thing about having the refresh token in a cookie alongside your session cookie is that if someone does get access to your session ID, they could potentially have access to it for for quite a while longer. But if you look at these hacks that are happening, for example, the Linus Tech Tips, YouTube got hacked a couple months ago. And the way that it worked is that there was some virus that got onto their computer.

And if you are on someone's computer, you can go into the bowels of your computer, like application support files, and you can you can grab the Chrome data from that. And you could basically just take that Chrome data cookies out and then paste them into another Chrome instance, which is gonna be somewhere else on a computer. You refresh the page. Boom. You're signed in as that user. Almost always, they're just gonna they have, like, a bot that's gonna immediately do what they want, which is delete all your videos, put up some crypto scam, and it's just gonna happen immediately. Right? But Mhmm. I guess, like, they if they wanted access to it for even longer, they could just keep refreshing

it with the with the refresh token. But you're you're kinda screwed either way, I think. Yeah. Yeah. And if you're wondering about, like I think it's pretty common too to, like, hash your refresh token if you're saving that into the database somewhere as well. There's some patterns around there. But yeah. Like I said, you're kind of pooch ed either, right, if they've they've gone through those links.

Last question from Corey.

I sometimes find myself stuck in a hole trying to fix a TypeScript error. When I know the code works fine and it feels like a waste of my time, is it alright to leave TypeScript errors as they are, or is the goal to have a 100% TypeScript error free code? This is kind of an interesting question. I thought you get our thoughts on it. Yeah. Sometimes you think, oh, there's a TypeScript error here, and you you go, oh, what is that? And you pull at it, and it sort of unravels and you go, oh, wow. This is this is much bigger than than I thought it would. Right? You're just 18 levels of inference deep, and I don't know if I'm gonna be able to to fix this type of thing. And and it works fine. I've many times in my life, I've been like, it works fine. But you also know how many times I've also been bit by saying it works fine? That's not gonna be undefined. Yeah. You know? Yeah. That's that's a big 1 for me is that's not gonna be undefined.

Yeah. It might be, you know, put in a use case for it. Sometimes it's it's annoying.

In those cases, you just check yourself before you wreck yourself and say, is this am I just annoyed because I wanna get it over with, or am I annoyed because I'm not understanding something? So, obviously, dip into it a little bit more. But at a certain point, whether it's like a a dependency doesn't have really good types or whatever, I think it's either okay sometimes to to leave them, leave a, TS ignore in there, or you can do, like, a, like, a cast or where you say as. Often, I'll find myself looking into libraries.

I mean, like, well, how are they doing it here in this library? And and you look deep, deep, deep, deep, and then it's just a It's gas. Yeah. It's just it's just coursing it into a specific type. So I think in some cases, that's fine.

Obviously, TypeScript is there to help you. And if you are turning things off, you really, really have to Node, I know better than this and not this is weird. Why is this happening? I just turned it off because there's probably something deeper there. Yeah. Check yourself before you wreck yourself. TypeScript errors, bad for your health. Mhmm. Yeah. But what what do you think? Have you do you ever I don't I'm trying to think if I've ever, like, just turned it off because I'm I don't know. In in my, like, production apps, it we even went through a lot of the the syntax ones. I don't think I've turned any off. Almost always, I'm able

to dive in and actually fix it. I only turn them off if I need if if I have my settings saying, you need 0 TypeScript errors for this code to compile. Right? To block the compile with errors, I'll occasionally turn them off while I'm debugging just to check to make sure the code is running or working or something Mhmm. Before trying to solve, like, a a like a a meaningless TypeScript error because sometimes there's some, like, odd ones here and there. I'm like, this works fine. But let me just let me just actually get this going so that I can and and try this for a second in browser.

I'll try it for a second and then remove the the ignore or whatever. So I pretty much don't turn anything off. If anything, I turn off the ability to block the compilation with errors. Because I don't I especially if I'm converting something to TypeScript or, I validated or tested it pretty Yarn. I don't I don't mind shipping TypeScript errors in that regard.

Mhmm. There are people who will comment on any TikTok video, like, you can't fix all the TypeScript errors. Are you are you dumb? And it's just like, well, I mean, there's sometimes there are situations where either whatever casting is required or, you know, maybe even the vendor types are iffy or all sorts of stuff. So, yeah, the sometimes you need a little extra help, and sometimes you can turn them off for a second. But just be aware of what you're turning off and on and test thoroughly and Beautiful.

Alright. Let's get into the next section of the show, which is sick picks. Do you have a sick pick for me? Yeah. I have a sick sick pick for you. I I don't know about you, Wes. This is gonna sound like an infomercial. I don't know about you, but I had a really hard time finding, you know, deodorant that wasn't, I don't know, like, bad.

Like, they're they're either deodorant either, but it doesn't work or it's It's gonna kill you. Gonna kill you. Right? Yeah. And so, yeah, I was so annoyed by this, and I I went looking and I found, course, on Reddit because, you know, you'll find recommendations for anything on Reddit.

I found this stuff which is like this it's like a a small company. They make it by hand.

And they kind of explain how it works Wes it's really just they're they're using, you know, all natural ingredients and stuff, but it actually works. And the 1 thing that I really like about this compared to a lot of other, natural deodorants is that, like, it lasts forever.

I don't know if it's just because of the the texture of it. It's a little bit harder or something like that, but it lasts forever. The sensor, Node and manly.

If you're a man, you might like this. There's also soaps and stuff like this, and and it's a small company, so you feel nice for supporting it. Now I don't I think it's expensive compared to most deodorants, but I wanna stress that they last forever. So I, like, hardly run out of these at all. And,

I I don't know if I had to replace it. Does it crumble and get all over your shirts like all the other stuff I've tried?

No. It's a little thicker. You kinda have to do get used to like, you know, you don't cake it on. It's just, like, 1 pass and you're good. Yeah. It's called the black stuff. Sorry. I did not say that. The black stuff Scott. And, again, the sensor are all really great. It's a small company. You feel good about buying from them. And, again, it's more expensive than normal deodorant, but any of this stuff JS. And it lasts me forever.

So I've now I've now tried 3 of the different scents. And I have to say, I'm a fan. Who knows when I'll have to buy another 1 because 3 is a Scott. But big fan.

Oh, man. You can pry my Old Spice 80 pack from Costco from my cold dead hands. I've tried so many of these, and, they either, like, pull my armpit hair out or get all crumbly on me. Maybe I'll just throw a Scott. But, yeah, it's I hear you. That's a hard world. You've probably tried a whole bunch of them.

I have. And that's why I've that I'm I'm I'm stoked that I've landed on 1. And and I don't wanna say this is not like some. I I didn't just get these. I've actually been using this for, like, 6, 7 months now. So, Node know, it stinks long term. No one's made any comments.

No. It's important to, my wife and I that I do not stink.

I'm going to sick pick a kind of an interesting charger that I put in our bathroom. So in the bathroom, I have to have some sort of charging block because I have to charge, my Waterpik. I charge the, my beard trimmer, my toothbrush, and, like, I've always had, like, a USB in there, and I'll plug them in. You only have to charge it, like, once every couple weeks. So it's just you plug it in and then whatever.

But I've always thought, I wish I could charge my watch in the bathroom because I usually take it off right before I get in the shower, and then I go, I don't wanna go run and get the the charger. So I got this 1 that it's like a charging block that has USB a and USB c, but then the top of it is an Apple Watch charger. And you just lay the the Apple Watch over top of the charging block, and it's really nice because it's nice and compact. It just stays in the the plug at all times, and you can just throw your watch on it. You get a couple, I don't know, 10% or whatever charge. It depends on on where your watch is at. Couple percent, and it'll, give you a little boosty boost for the day.

And I'm a big fan of it. I was thinking, like, I wish that there was something like this. And then I went out there and thought, oh, somebody has made this.

It is good. That looks awesome. Yeah. I would use that for sure.

It's and it stays in. Like, it has kind of, like, a wide flange base on it so that when you put the heavy watch on it, it doesn't, like, fall out because the everybody outside of North America knows how shoddy our plugs are here Wes, you know, it'll, like, kind of come out, and there's no fuse in any of our stuff. So, like, you can literally just drop something across the the neutral and and hot, and it'll spark. So that Wes a concern of mine.

Yeah. III didn't tell you. I got I got Oh. The the latest the latest series 10 or whatever Apple Watch. I didn't go with the Ultra just because I wanted it a little bit slimmer profile because I wear it while dancing, and I don't wanna Yeah. Whack it on the ground.

So, yeah, mine mine Wes, like man, mine was 1 of the first ones. It's, like, series 4, series 3, so I've had it forever. Big upgrade then. Yeah. It feels like a completely different class of device. It's, like, completely it's it's shockingly different. So, yeah, shout out to the Apple Watch. You know? I was the Apple Watch hater for most of my life.

Being like, you don't need I don't need another thing to give me notifications and and all the annoying stuff, but I freaking love it. I have the Ultra Series 9 Ultra, and it's on all time.

And I love that it gives me all my sleep stats, and I find that I bring my phone out less now that I have it on. Because, like, if if your phone buzzes, you just go, that's nothing. You know? And especially for, like, security cameras, I love being able to just quickly glance and, like, is there actually somebody at the door, or is it just a a leaf that blew in the wind slightly?

Totally. Word.

I'm gonna shamelessly plug Syntax on YouTube once again. I feel like we're always shamelessly plugging this. But, hey, the Syntax YouTube has been popping off lately, and we do a ton of great stuff over there. So ESLint youtube.comforward/at syntax f m. Again, we're releasing all of these episodes plus way more, like, way more deeper dives. CJ Reynolds is doing some crazy good stuff. I'm releasing or have released at this point a Svelte kit or a Svelte 5 course. So if you want an introduction to Svelte 5, maybe you've never used Svelte at all, this is for you because I'm not assuming that you've ever used Svelte in this course. And it's enough to get you going, cover the basics, get you up and moving, and, a little toss in some little if you use React stuff here and there. But for the most part, just get you up and running is is really the point. So check it out. Youtube.comforward/atsyntaxfm.

Beautiful. Alright. Thanks, everybody, for tuning in. Catch you later. Peace.