856: Loading UIs, Rust Webpack, New Cookie Types, Conference Talks + More

Scott and Wes dive into your questions on Hono and SvelteKit, partitioned cookies, redirect codes, and using Rspack instead of Vite. Plus, they share insights on quoting projects, interview best practices, and whether you should slow down those speedy loading spinners. Show Notes 00:00 Welcome to Syntax! 00:50 Brought to you by Sentry.io. 02:23 Apple developer accounts and certificates. 06:58 Hono, SvelteKit, and using them together. 11:14 Rspack & Rsbuild over Vite? Rspack, Rsbuild. Rolldown, Rollup. oxc. Turborepo. 21:01 Quoting projects without seeing under the hood. 25:26 HTTP cookies, partitioned cookies, and chips. Partitioned Cookies. 30:29 Redirect codes; 301, 302, 303, 307 418 I’m a teapot. 36:22 Gaining inspiration for talks and posts. 40:02 My loading state is too fast! Should I use setTimeout? setTimeout Docs. 42:29 Interviews and landing the job. 49:50 Sick Picks & Shameless Plugs. Sick Picks Scott: Stainless Steel Cookware. Wes: Dim Lightbulbs, steelpan.guy on TikTok. Shameless Plugs Scott: Potluck Submissions. Wes: Syntax on YouTube. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax. Today, we got a potluck episode for you two. It's you bring the questions, we bring the answers. Some really good questions today around, should you be adding time to your loading spinners so they don't flick off so quickly? Quoting work for existing websites, so you're going to do some work on an existing website? And how do you know what lies on the backend? Is it going to be awful? Is it going to take you a long time? How do you figure that out? Partition cookies is kind of a new thing to how cookies work. We're going to dive into that. Should you use Hana with SvelteKit or Remix or something like that? Or is that not really a use case? And some questions around the interviewing process as well. Let's get on into it.

• 0:50Scott Tolinski?

  Before we do that, let's go ahead and take a quick second to check out Sentry. Sentry.io is the perfect place to track and solve all of your bugs. Man, I ran a big migration, a big whole migration on the codebase recently. And I pushed to production because nobody gave me a code review. Wes, I'm just going to say that nobody gave me a code review. It's very sad. I requested several code reviews and everybody said I'm too busy.

• 1:17Wes Bos?

  No, I gave it a look over.

• 1:19Scott Tolinski?

  No, I know.

• 1:19Wes Bos?

  But I wasn't, you're the Svelte master, so.

• 1:24Scott Tolinski?

  Yeah, it also touched like 100 some files. Like, I mean, it touched the whole, the whole app. So I'm just, I'm being cheeky here. But either way, we ran a whole big migration and there is one bug that keeps coming up from that migration, something about a proxy object could not be cloned. And let me tell you, I'm going to fix that bug today because it was really just the assurance of knowing that I could, one, our test pass, the code builds, I manually tested it. But I know that if I push it to production and there's something wrong, we're going to see it in Sentry and then I'll be able to make sure that gets fixed. So this little proxy object could not be cloned bug will not be sticking around for

• 2:04Scott Tolinski?

  long because we've had 29 instances of it in the past 24 hours, which isn't a ton. That's not a ton. So it's clearly not hitting that many people, but something is happening there and I'm going to find out what. So thank you Sentry. Sentry.io/synthax signup and get two months for free using the coupon code TASTYTREAT.

• 2:23Scott Tolinski?

  All right, let's get into it.

• 2:24Wes Bos?

  All right, we've got lots of really good questions for you today. Again, if you want, if you've got a question, please send it to us. Go to syntax.fm and in the URL bar, there's something that says Potluck. Click on that, send us your question or thought or really send us anything and we'll answer it on an upcoming episode. The first one we have here is from Justin P. Scott mentioned that sending his Tori app from Hack Week to the rest of the team was tricky and required some Apple foo for signing and certifying the app. I'm curious, what is required? Thanks, everything on syntax. Yeah, this is an interesting question because when you build a desktop application or even like when I

• 3:04Wes Bos?

  want to run apps on my Samsung TV that are not in the store, you have to do a whole certificate signing process. So what is that like, Scott?

• 3:16Scott Tolinski?

  Yeah, so for the process in Tori, one, if you're distributing on Apple and you want the app to open without a message that says this app is damaged, which is when I first sent it to the team, I didn't realize that it would, it would come with that message. I thought it might just be like, this is an unapproved developer, click OK, that message. But no, it was like, this application is damaged. So I needed one in Apple Developers Account, which I already had. It's shaky because it's under my LevelUp Tutorials LLC and not under Syntax, but we're not distributing it to anybody, so it doesn't matter, right?

• 3:51Wes Bos?

  Yeah.

• 3:52Scott Tolinski?

  I just needed to sign it. And the process involved creating several certificates. Now, it was interesting because I'm trying to pop open the docs right here because what you first had to do was create a signing certificate on their website. You had to download the certificate, you had to put it in your profiles, you had to configure Tori, you had to sign it locally, you had to have basically everything in your config. You had to run some commands, you had to open some things in Xcode. I basically, there's, there's-

• 4:25Wes Bos?

  It's a lot of work.

• 4:26Scott Tolinski?

  There's a couple of pages on Tori's docs that explain exactly the process. And if I'm being entirely honest, if I had to do it a second- Second time here, I would have to look at the docs again because it's just like step, step, step, step, step. All right. Now that you're ready to go, you've done everything, your certificate is loaded up into X code. When you build the application, if you have all of the proper information set, it should then be signed. Now, I don't even know the process of getting it into the App Store. There's docs on that as well in the, uh, in the Tori documentation, which is actually really good for this stuff. But really, when you're done and you build the thing, you end up just getting a DMG,

• 5:05Scott Tolinski?

  which is a disk image and I can pass that disk image around, load it up and that's it. So, uh, the, what, what is required? Basically, you need an Apple Developers account. You need to create that signing certificate and then just follow the directions in their docs. Cause it's, yeah, it's different than, um, you know, pushing go and having a website deploy, right?

• 5:25Wes Bos?

  Yeah. And the, we should say the benefit of, of having an application signed is that not anyone can just come around and replace that application, you know, like you leave your computer open and you swap it out with a nefarious version. The operating system is going to, it's similar with the HTTPS certificates or whatever the certificates are called. Where it's going to throw a fit if you, somebody nefarious tries to replace or tamper with that. Cause that's another thing as well. It's like, it could be the application, but if you then change it, that's part of the reason why it's hard to change

• 6:04Wes Bos?

  or add CSS to VS Code as well, because you're literally tampering with the runtime of the application.

• 6:11Scott Tolinski?

  Yeah. Which is funny, uh, because when I use the APC, I don't even know if that works anymore, but when I was using APC for VS Code, VS Code had no problem with you modifying those files. I mean, whatever they did made it so VS Code had no problems with. But the same process on Cursor, Cursor immediately says Cursor is corrupt, can't do anything, you know? And all it's doing is modifying some CSS files and the app still loads. It still works, but like a little toast message pops up and it's like, there's something wrong with your install.

• 6:41Wes Bos?

  Yeah, it looks like. The APC did get is now broken within a latest update to VS Code?

• 6:49Scott Tolinski?

  Yeah, I think that was just due to a file name changing and then the developer just hasn't updated it yet.

• 6:55Wes Bos?

  Hasn't updated it yet. Okay, interesting. Next question from C-Dog. I enjoyed your content on Hono and SvelteKit, but is there any point in using them together? This is a great question because yeah, we talk a lot about, oh yeah, if you want a backend stack framework, then you gotta use Hono. But if you want to build an entire app, both frontend and backend, then maybe reach for SvelteKit or NextJS or Remix or TanStack Start or any of these like full stack frameworks, right? And the answer to that is, is no, you probably don't need Hono or Nitro is another one in the space as well.

• 7:36Wes Bos?

  If you are using a full stack framework, and in fact, TanStack Start is built on Vinci, which Vinci is Veet and Nitro together. Essentially, if you want to build your own stack or you have some existing legacy codebase that you want to move over, maybe you'll reach for Hono and Svelte. Or if you just you want to make your own custom framework, then yeah, you can do that. But if you are starting fresh, no, you can go straight in and just grab SvelteKit, NextJS, Remix, TanStack Start, any of those.

• 8:08Scott Tolinski?

  Yeah, you know what's interesting about this question, Wes, is that I, there was a post on Reddit a while ago, and I'm trying to find it where people were like asking about this stack and they were saying, I'm using SvelteKit and Hono or Hono. And I'm like, so many people in the comments were saying, that's awesome. I do the same thing. I do the same thing. And I'm just thinking, why? I don't get it. And sure, I guess if you're moving over or if you want a completely separate process to control your backend, right? But man, it's so easy to do the other way. Yeah, I get maybe having a separate backend. But at the same time, man, you can host a full API, just an API via SvelteKit.

• 8:53Scott Tolinski?

  You can have endpoints. It feels flexible enough to me that unless I really had an application that I was keen to scale in a different way, I would, I would pretty much never reach for having a separate backend.

• 9:08Wes Bos?

  A separate backend. Yeah, I think there's, there's probably still use cases, especially if somebody has an existing backend. Because if, if you were like trying to pitch to your, your team, like, all right, we have an Android app, we have a React Native app, and we have a website. What are we going to build our API on? I don't know that people would say SvelteKit, you know? Because like, you kind of have to use the Svelte part of that to make that, that really worth it. It would be really odd to do that. And, and if that's the case, yeah, you, well, you can use Hanno and SvelteKit together, where Hanno would be, you build your entire API, right? You put your,

• 9:47Wes Bos?

  your drizzle schemas in there, you do all of your middleware, you do all of your caching and access control, everything would happen inside of there. And then your Svelte server side would be very, a very thin layer that would simply just import the Hanno API, and you can use that to, to hit your API endpoints, get your data and whatnot.

• 10:12Scott Tolinski?

  Yeah, that makes sense to me. I was seeing people asking if they could literally embed Hanno into SvelteKit. Like, can I have Hanno routes inside of my SvelteKit server side? Which to me makes no sense whatsoever. I can understand separating, especially separating your UI from your, your API in terms of the codebase. That, that's no problem to me. But I, like, I've never needed a replacement for SvelteKit's own endpoints within SvelteKit.

• 10:40Wes Bos?

  Yeah. Like, the router is so core to these things, that if you all of a sudden had two routers, that might be a little bit funky. I'm sure you could do it, but I don't, I don't think that would be very fun.

• 10:53Scott Tolinski?

  I don't get it. Yeah. Any point in using them together? Yeah, I think we, we kind of hit all of the different reasons why you may or may not want to use them together. If I was having to have a separate API server, I probably would pick Hanno today. If that, or a separate backend server, whatever, just because it's the one I like the most out of all of the, the available options. All right. Next question from Jack Broomer. Hello. In many of your episodes, you talk highly of Veet in both ease of use and raw performance. However, I don't think I've heard you guys mention RS Pack RS Build. I personally have found it much easier to migrate from CRA with some custom Webpack

• 11:34Scott Tolinski?

  extensions to RS Pack. I think I spent more than a week trying to make Veet compile esoteric module oddities versus less than an hour for RS Pack. While we're not using RS Pack for production builds this yet, it has sped up our local development builds from one to two minutes to less than five seconds. Yeah. Local development builds, one to two minutes. Woof. That's all I gotta say there. Thanks for reading and love the show. Yeah, totally. I think for me, one of the reasons why you won't hear me mentioning RS Pack very much is specifically because I did not use Webpack. I'm one of the few lucky

• 12:15Scott Tolinski?

  developers who got to skip Webpack entirely. I did not ever work on anything with Webpack. I did Rollup, I did ISO Build, I did Veet, never did Webpack. So that is the main reason why you don't hear me personally talking about it. But RS Pack is a, is a very cool project. And definitely, I think one of the things that Webpack users have been missing out on more recently is seriously just the speed of this modern tooling, whether that is via ES Build, Veet, or now RS Pack, or any of these new faster tools that have been just really, really cruising on it. One that I'm, I'm super interested in, and you know,

• 12:59Scott Tolinski?

  the Veet team is, is all about is Rolldown. And Rolldown is a fast Rust bundler for JavaScript and TypeScript with a Rollup compatible API. Now, this is like, kind of, I think the future of Rollup for them, because Rollup, by the way, you know, you know, Rich Harris created Rollup, right?

• 13:19Wes Bos?

  I actually did not know that until I was writing the notes for this question. I was like, oh, Rich Harris wrote Rollup?

• 13:26Scott Tolinski?

  I had used Rollup before in the past and I had, I'd remember seeing that. And yeah, Rollup, Rollup, awesome, awesome build tool in the past, but definitely more of a, we use what ES Build for, for development builds or whatever. So either way.

• 13:41Wes Bos?

  Let's, let's explain that. This, this thing about Webpack is there's so many people that are, have huge applications on Webpack and there is no hope for them to move over to Vite. Either because they have, they've built a whole bunch of custom loaders that are specific to their company. Or it's just, it's just, it's such a tangled mess that it, it's not worth even moving over. And the, there's tons of people, they built their whole app on Create React app, you know? And then at some point you eject out of Create React app and then you have your own Webpack build. And then there's maybe you have some Babel stuff built in there, you know? And it's just like, it's not, not worth moving over, you know?

• 14:22Wes Bos?

  So RS pack is a Rust based implementation of Webpack. And it's such a good, such a good solution to if you have a slow Webpack is try RS pack. Because it supports most of the Webpack API. There's also Turbo pack from the folks at Vercel. They actually hired the guy who built Webpack to build Turbo pack. And it's pretty close. I still hit, I tried moving a couple of next JS sites over to Turbo pack. And I still hit a couple of issues around web workers and MDX plugins don't work yet and whatnot. So I had, again, I had to switch back, which is kind of annoying.

• 15:05Wes Bos?

  But Rolldown is, is awesome. So Vite uses ES Build in like development to just transform a JSX and things like that. And then when you want to build, they use Rolldown. So they have two different bundling tools.

• 15:20Scott Tolinski?

  They use Rollup.

• 15:21Wes Bos?

  Yeah, Rollup. Yes. But the idea with Rolldown is that it will replace both ES Build for dev and Rollup for, for production. Which that's kind of wild that Vite uses two different tools. And I don't think I've ever hit a Inconsistency between the two and like you think like, oh, running a different tool in Dev than than Prod, that seems risky.

• 15:47Scott Tolinski?

  Yeah, I, I don't, I mean, I don't have any issues with it personally. I think they're, they've really figured out whatever that is. But by the way, um, RollDown is, is built using OXC, um, which is something we've talked about quite a bit, which is the JavaScript oxidation compiler. I don't know what oxidation means here, but basically it's a, a Rust based compiler for JavaScript that we've talked about quite a bit on this show, but that's what RollDown is using, um, to do its stuff, to do its compilation, at least.

• 16:19Wes Bos?

  Yeah. And that's, we're gonna, we're actually having Evan Yu on the show in a little bit, and he basically just started a company to fund all of this stuff, right? Cause there's, there's V, Vtest, RollDown and OXC. OXC is, is under the hood for RollDown. So there's, yeah, he's doing a lot of stuff for the, the, the industry. That's my one like, uh, caveat of, of NextJS right now is that like, it seems like NextJS is the only one sticking on Webpack and everybody else is on Veet. And, and Veet has such a, like, obviously TurboPack has, has a good future as well, but it's, it seems a bit odd where things have to be a little bit different in the Webpack world.

• 17:04Scott Tolinski?

  Yeah, I know. Uh, Veet has such, it has such a great big community and a ton of stuff behind it. It just, it feels like that's such a huge selling point. The Veet community is really big and strong. You mentioned, uh, TurboPack, not really related other than by, you know, where it comes from in the name, but Turbo Repo is something I've really been diving into a lot lately, Wes. I don't know. At first I was not sold on needing a, a thing like Turbo Repo, but man. Uh, so for people who don't know, Turbo Repo is a It's a way to kind of manage your dependencies, to manage your build in a way that it can cache

• 17:46Scott Tolinski?

  your build, it can make your mono repo stuff easier, can run a whole bunch of commands at once. Man, I added Turbo Repo to my starter, my drop-in starter.

• 17:57Wes Bos?

  Yeah.

• 17:57Scott Tolinski?

  And it has made developing that thing so much easier with being able to work in my workspace so much better. So shout out to Turbo Repo. It's one of those tools that I kind of was like, I don't need this. And then now that I tried, I'm like, what's that meme where the bird is like angry and then it eats the cracker and then it's like...

• 18:15Wes Bos?

  Yeah, it's like, ah, it's actually pretty good.

• 18:17Scott Tolinski?

  Yeah.

• 18:17Wes Bos?

  Yeah, I run Turbo Repo on my courses platform. We had Jared on. Actually, he friggin' did a call with me and helped me set it up. What a good guy.

• 18:30Scott Tolinski?

  Nice, man.

• 18:30Wes Bos?

  And yeah, basically you can like do, I have like a mono repo and I have like three different like apps and those all have dev commands. So you can say turbo run dev and it will run the corresponding dev commands for all of them. And then when you build the thing, it's smart enough to know which parts need to be rebuilt and then it will also cache them in the node modules directory. So when I go to deploy the thing, it, because my, I use render, but this is the same on many CI's, they will cache the node modules directory so that you don't have to npm install every single time. And what they do is they

• 19:11Wes Bos?

  stick the cache of your build in the node modules directory so that the next time you run a build, it goes, hey, I left this here last time and it pulls it back out. And then the like the further benefit, and this is the, this is like how they make money, both Turbo Repo and Evan used new Void Zero, I bet is gonna do this, is they do like remote caching, meaning that like if you run a dev command on your computer and some of these apps take, like this guy just said, takes five minutes to run a local dev command just to start the whole thing up because there, there's a lot that needs to happen.

• 19:51Wes Bos?

  If you do that on your computer, now you can then share that cache with other people, both in dev as well as as production. So you could have... Really speed it up. There is one caveat that I've hit, though, is that every time I run Turbo Repo, it sticks the cache in my node modules, but then my node modules continues to grow. And, and part of the CI is that it restores the node modules. So at a certain point, it's much slower because the node modules restoration is so large. So every now and then I have to blow the node modules cache away because it's faster to npm install and do a fresh build

• 20:35Wes Bos?

  versus use the cache, which is kind of hilarious.

• 20:38Scott Tolinski?

  Yeah, for people who don't have this, I highly recommend just dropping a script into your shortcuts or your aliases or anything that is just nuke all of the node modules from a given directory. I use that somewhat frequently, or even better, I have a, I have a clean command in my package.json that does all that for me.

• 21:01Wes Bos?

  Next question from ItDepends. How do you quote potential clients on the cost of updating their website if you don't have access or inside knowledge that they have already built? Considering factors such as the previous agencies worked on the site and their reluctance to help another competing business is, yeah, that's true. Potential clients unable to give or grant access to the code or CMS that their website uses. Yes, this is a thing I hit all the time. Oh, cool. Can, can you give me access so I can just kind of poke around? Oh, I don't know who, who has, who has the password to that. It's terrifying that so many businesses don't have control over their own web presence. Goes on to say typically

• 21:45Wes Bos?

  clients do not have the faintest idea of the tech that went into their website or how it was built. And when you come in as a freelancer new agency, you have no idea how much it costs to quote. Where do we even begin on this type of thing? Yeah, it depends, right? The, the answer to this is you need to.

• 22:05Wes Bos?

  Do your research into it. And if you can't access it, you're going to need to be able to access it eventually. And I get that they're probably trying to just kind of suss it out, be like, hey, how much would it be cost to add a page to our website? I think you can, you can give them a bit of a ballpark. If you know, just by viewing source, you can usually figure out viewing source, looking at the headers of the request, you can usually figure out what the backend is built in. And you can kind of get a decent idea for what it is. But quite honestly, I would say, hey, it's going to be this crazy wide. If it's what I think it is, here's, here's my idea. But if it's something that's

• 22:48Wes Bos?

  totally different, it might be a little bit more. But I don't think there's any other way around this than a wide estimation, or just getting full on access to this thing. So you can poke around. And certainly, I would not want to quote something without giving a, without having to poke around at it. Because you don't know the awful crimes that have been committed by the previous developer before you.

• 23:12Scott Tolinski?

  Yeah. And even if, I mean, I think even like, at the very least, at the very least, you, you know what the system is and like where it's hosted. Okay, this is a WordPress site being hosted on Bluehost. Yeah, I know that there may be dragons in this codebase. Maybe even you could give them a bit of a quote, or a range of a quote with the preface of, just so you know, this is like, this is the, this is the scenario if this was how things are typically. You could think of it as like this, like, have you ever got like a remodel being done or something like that? And then let's say, you're just simply like

• 23:54Scott Tolinski?

  doing some tile or something. They pull off the tile and they find a bunch of mold. Well, that project is going to balloon in costs comparatively to just replacing the tile. I don't, I don't even, I've never had this been done to my house before. But I'd assume that's the case. That makes sense. At least I've seen it on, on home flipping shows, right? So.

• 24:14Scott Tolinski?

  I think you could take that approach and say, this is what it should cost. But again, try to get as much information as possible because knowledge is power in this situation and you want to make sure that that quote is good because if you quote too little, project takes up too much of your time, you're either going to eat that cost or you're going to, you know, make the client angry or something like that. And trust me, I've had situations where, especially early on in my career, where I felt like, oh, I'll just say yes to all this stuff because I'm trying to get in, I'm trying to get some experience, I'm trying to get some clients. And like, only a handful of times did that work out well for me, where I just like pushed through something that, you know, I knew was not

• 24:56Scott Tolinski?

  a good idea necessarily, just based on the way the client is acting or what it is. And then, you know, that stuff only ever, ever gets worse over time, or the further you get into it, right? You say yes to a client, you think that client is like, maybe, well, they might be a little bit hard to work with, but I'll just knock it out and do whatever. And then you never know. So, yes, get as much information as possible. And any quote that you do give them, without seeing the code, make sure that they know that it could potentially rise in cost. Next question from Christian. Hi there. I really enjoy syntax while driving. On the last Potluck session, you talked about cookies. I have two comments.

• 25:35Scott Tolinski?

  First, HTTP cookies are readable by extensions, which was surprising to me, too. Feel free to look it up on my LinkedIn. Secondly, I would love to hear your take on partition cookies, AKA chips. One more unrelated things. Can you share tips on how to get more inspiration, talk ideas, post ideas? Love the vibe of the show. So I'm going to start first with the cookie business. And you are totally correct, Christian. HTTP cookies cannot be read by the client. JavaScript can be read by extensions, which apparently, extensions have that layer of permissions that the client doesn't have that allow them to reach HTTP

• 26:18Scott Tolinski?

  extensions. I did confirm this, and that is in fact correct. I didn't know that. Thanks, Christian, for that.

• 26:22Wes Bos?

  I wonder what the use case for that is. That seems...

• 26:26Scott Tolinski?

  Auth maybe? I don't know. No, I had no idea. Yeah, auth inside of cookies? Or auth inside of extensions? Because extensions can't run on the server, so...

• 26:37Wes Bos?

  Oh, yeah. Yeah, if you want to be able to set an HTTP-only cookie from an extension, or, but then you need to be able to read it.

• 26:46Scott Tolinski?

  Yeah, what if you wanted to read it? Yeah. Also, he mentioned chips or partitioned cookies. Man, Christian brought the heat because this is also something I had not heard of. Partitioned cookies, which are not available in every browser, so I want to throw that caveat out there because partitioned cookies were something that had been in Chrome for a bit, were only added to Firefox in September. What month are we in? November? So, what, two months ago? So they were just recently added to Firefox and are not in Safari at all. But what these things are is basically they're partitioned cookies so that... Let me give you a use case here. Let's say you have like an iframe comments widget. Think something like Discuss, right?

• 27:31Scott Tolinski?

  Users could stay logged into the comments widget on each individual blog that they have signed in on, but the comments widget itself can't track users across those blogs. So each blog gets a separate, independent user state. Blog owners get common functionality without compromising user privacy. So basically, you would have one cookie. It would be for both comments widgets on one page, like you'd stay logged into Discuss on both pages within that iframe, but they couldn't track you between those sessions. Which is not something, you know, I've had to do very much. In fact, I don't really even know that much about cookie behavior in iframes.

• 28:16Scott Tolinski?

  But historically, when a site embeds content via an iframe, the embedded content has been able to set a cookie on the user's device in response to a cross-site request. If the user visits other sites that embed the same content, the embedded content can access the same cookie originally set by the first instance of the embedded content. What a sentence, man.

• 28:39Wes Bos?

  Yeah. So this is...

• 28:42Wes Bos?

  Really nice because it can be used to track you across the web. So previously, what had, this was done with images where you would, let's say you have an image to adservr.com and you embed the image to adservr.com and adservr.com can set a cookie and it also knows who is requesting it. So it knows, oh, well, scott.com has been requesting this, so we'll set a cookie for that. And then also, and you go to wes.com and I also am embedding that image. Now it knows that you visited wes and scott.com. Now, that's not possible anymore. They, we've removed that. You can't just do it via an image tag because it was using, being used for nefarious things.

• 29:27Wes Bos?

  But there are some use cases where you do want to be able to, to have access to those cookies. So this will allow you to set cookies for a third party, but if it's then embedded on another page, like Scott says, you cannot access it. I could see this being really handy for like Shopify websites that run on like subdomains, you know, if you want to be able to run custom code on that page, third-party embedding widgets. This is surprising that Safari has not implemented this yet because they are almost always the first to implement these pain in the butt cookie things because Safari is number one

• 30:07Wes Bos?

  with like not tracking you across their devices, even though Apple, Apple themselves has their own whole ad platform for iOS, but on the web, they, they want to stop it. I'm surprised that Google and everyone has implemented it.

• 30:22Scott Tolinski?

  Yeah.

• 30:22Wes Bos?

  So that's cool. I had no idea.

• 30:25Scott Tolinski?

  I had never heard of this either. So yeah, you learn something new every day.

• 30:29Wes Bos?

  All right. Next question from TJ. Let's set the record straight on the redirect codes, 301, 302, 303, and 307. So let's, let's go through what those are real quick before we read the rest of the question. So 301 and 302 are probably the two that you're most familiar with, where 301 is a permanent redirect and 302 is a temporary redirect. And

• 30:53Wes Bos?

  When you would want to use one over the other is if you want it to be permanent or not. So for example, if you go to syntax.fm/856, we do a 301 redirect. And what that does is it, it looks up the episode for 856 and then we'll do a 301 redirect to, to the actual page. The reason we don't do a permanent redirect is because there's, there is a possibility that we will change the title or the URL of that. And if that's the case, we have no way to clear that redirect in the user's browser unless the user were to explicitly take some action to open up DevTools and refresh the page

• 31:38Wes Bos?

  or go into their caches and delete it. And it's quite honestly, a permanent redirect is very scary to me.

• 31:44Scott Tolinski?

  Yeah.

• 31:44Wes Bos?

  There, I guess there can be some SEO benefits to it, I think, but I almost always reach for the, the temporary redirect.

• 31:54Wes Bos?

  And then we also have 303, which is see other typically used to redirect after a post request instructing the client to make a get request to the new URL. So that's kind of interesting. So if you were to post some data, but the, you want to redirect it to a get URL. For example, if you were posting a search term, you may want to redirect your user to a page where the search term is in the URL when they get. And then a 307 is the temporary redirect similar to 302, but strictly requires that the HTTP method, get, post, put, et cetera, remain the same during a redirection.

• 32:38Wes Bos?

  All right, so those are the, those are the three here. Early 2000s train of thought was returning redirects was a very serious matter that it could negatively impact Google rankings if done correctly. So I think has been a little timid about setting up redirects. That's exactly what I just said. I'm still unsure if I should be using the correct one. I read that 301 and 302 are considered old, not as good and possibly bad practice. Rather, we should be using 303 and 307. If that is true, can you explain the difference between the new redirect codes? Speaking of HTTP response codes, my son was born on April 18th and I love it. Congratulations.

• 33:14Wes Bos?

  Yeah, this is a great question. I have also been using 301 and 302 myself as well, but I think it does make sense to explicitly enforce whether you are going to be changing the method of the request, meaning that you are going from a post to a get, or if you're going from a post to a post. So I don't see why you wouldn't want to use these things. Again, I probably don't use permanent until you're absolutely sure that you are doing a permanent redirect, because that can get you into some hot water. I don't know what

• 33:54Wes Bos?

  the SEO implications are for this type of thing, but I've just been using temporary redirects for all of my stuff, and I feel like I have pretty good SEO on all of my projects.

• 34:05Scott Tolinski?

  Yeah, my understanding is that those redirects, the permanent redirects, has always been taught to me as you better be sure. You better be sure that this is a permanent change, because that kind of tells the search engines that yes, this is always going to exist in this way. And if you don't know that, then don't do a permanent redirect. You know, I think that could be useful where something like a brand's name has changed, or something that has irreparably, you know, happened. You know, there's no going back.

• 34:44Scott Tolinski?

  So now that this redirect is happening. Whereas, let's say you just change a route from what it used to. You don't know that that route structure is going to stay the same, or that you might not want to use that previous route at some point, anything like that. So I would always, like you said, lean on being cautious with permanent redirects. But maybe we should both dive in a little bit more deep to what is that actual implication? Because I've been told that, but I don't think I have ever really deeply researched it.

• 35:18Wes Bos?

  I think there's probably also a security implication here where if you have a get URL that redirects to a post, there could be a use case where somebody clicks a link and that turns into a post request. And a post request could have, be changing some data or whatnot. And like, you'd have to actually make that security hole in your own code. But being explicit about whether or not the method is changing on this request is probably some good foresight to have. Because there are also use cases for changing the method as well. Because, for example, a sign in page, you post your username and password

• 36:01Wes Bos?

  to a URL, and then you do a redirect to your account dashboard, which is a get request, right?

• 36:08Scott Tolinski?

  Hmm. Redirects. Oh, by the way, for people who didn't get the April 18 thing, the 418 response is "I'm a teapot," which is the funniest response.

• 36:18Wes Bos?

  Oh, I didn't get that at all.

• 36:19Scott Tolinski?

  Oh, yeah. Oh, that's, it's great. So, thanks for that, TJ. By the way, I wanted to follow up Christian. By the way, the previous question asker had a second follow up. And since he had given us two nice little corrections, I figured we definitely had to answer his actual question, which was, "One more unrelated thing. Can you share tips on how to get more inspiration for talks, posts, ideas? Love the show and the vibe." Christian, whatever you are into, man, dive into it, go deep. And, you know, I think this partition cookies thing is a good example of this. I've never heard this. It would be interesting if a blog post came on my timeline that said, "Hey, have you heard of these partition cookies? They're new. Here's what they're used for. Here's what they're about. Maybe some visuals,

• 37:01Scott Tolinski?

  maybe this or that." Might even make a good little talk here, or if you can find like some interesting use cases that make practical, or even just cookies in general. That's a talk right there. Cookies. Deep dive.

• 37:13Wes Bos?

  Yeah, I think that would be a fantastic talk, because there's quite a bit there, you know, and they've changed. And what happens if you are signing in on a different URL? You know, like, that's a huge thing as well. You redirect somebody to a sign in URL that lives on like offzero.com, and then you come back to your website, and how are those cookies shared? And then there's also this weird thing that I stumbled upon with cookies once, where if you host on

• 37:44Wes Bos?

  dot versal.dev or github.io or any of these like if you use a platform as a service and you host multiple, for example, at the time, I think it was, I ran like app1 dot versal.com and then app2 dot versal.com and they, I was setting the cookie on the, the main domain in my application, which was like versal.com or, or whatever the versal hosting one is or github.io. But I couldn't access the cookie from the other application. I was banging my head against the wall being like, why doesn't this work? Cookies are shareable between subdomains. And the reason

• 38:23Wes Bos?

  why is that the browsers maintain lists of domains that are interpreted as top level domain names, meaning that like github.io is treated as if it were dot io. And because multiple people will be hosting applications on the same domain name, that's not a good idea to be able to do it. So the browser has a whole list of dot code pen and all of these, these services where you can host code.

• 38:55Scott Tolinski?

  Hmm. Yeah. You know, one thing about that, even that, that apex domain thing, that's called apex domain, where you don't have a subdomain on it. Do you know WWW, people might not know this, is considered a subdomain, right?

• 39:08Wes Bos?

  Yes.

• 39:09Scott Tolinski?

  And that's a good reason to use WWW if you have a cookie that you need to be across the domain. I ran into issues with that personally, where I was setting a cookie from a subdomain to an apex domain and it was causing some problems. I, it was a little while ago, so I might be a little foggy on that. But yeah. One last thing before we get off this question. Christian, I think the best way to come up with stuff is to find something you are slightly interested in and maybe not an expert in or anything like that, and use it as an opportunity to dive deep into a subject, right? I think that always works because if you got a better way to talk about it.

• 39:51Wes Bos?

  Learn something than just to, to talk about it, you know? If you're explaining it to somebody, you're going to learn a lot about it.

• 39:58Scott Tolinski?

  Yep, totally. And get your hands dirty, all that stuff. And then, yeah.

• 40:02Wes Bos?

  All right. Next question from Mike. What are your thoughts on using a delay of about one second when turning off a loading state? For example, when you go to fetch some data, displaying a loading state of some kind while it's fetching and then display the data while it returns? The problem is sometimes the data returns so quickly that toggling between the loading state and displaying the data seems clunky and conflicted. And I don't want to make my users wait longer to see the data, but I also want to keep the UI feeling nice. Absolutely. This is a really good thing is if you, your users are on a fast connection, sometimes the loading state is just like a little blip, you know, and it's just a split second.

• 40:44Wes Bos?

  And it just looks odd. The answer to that is don't add more time to waiting the user. So to answer your question, don't do this. Adding time to showing up the UI. The answer to this is simply don't show a loader until you hit a, a specific amount. React Suspense used to actually have a delay prop that is sent. So React Suspense, what that does is you wrap your component in a suspense tag and then you can provide the suspense tag a fallback, which is your loading screen, right? And it will show your fallback while it's waiting. And there used to be the ability to supply a delay to that, meaning that like, don't show anything

• 41:28Wes Bos?

  unless like you put a 400 milliseconds or 200 milliseconds on it. Because like, if you're just showing a loader for 36 milliseconds, that doesn't make very much sense. I think they took that out. You have to implement it yourself in your, your fallback now. I don't know. I think that's true. Sometimes the best feeling UI is showing the user absolutely nothing at all.

• 41:54Scott Tolinski?

  Yeah, that's, that's totally correct. I think loading spinners or loading states in general are a problem. You know, it's not something you want to introduce if you don't have to. So, yes, by all means, the way I handle this is very much what Wes said. I, I, if, if the loading time has taken more than what like 300 milliseconds or something, then I might show a loading spinner. Other than that, yeah, definitely do not introduce time into that loading. Uh, because you want to keep, yeah, that one second definitely matters. You want to keep, you know, people on your site happy. All right. Next question from CJ. So not CJ Reynolds probably, but CJ nonetheless. Apologies ahead of time if

• 42:36Scott Tolinski?

  something similar has been asked before. I just discovered you folks. All right. Not CJ Reynolds. Welcome CJ. This is a question that could do with much more context, but I'll keep it short. What are your folks thoughts on the current way interviews are done? And if available, how would you factor in past worker side projects in the decision-making process? I wanted to ask this as I had a technical interview where I admitted, admittedly, I can't say that word Wes, admittedly.

• 43:06Wes Bos?

  Admittedly.

• 43:07Scott Tolinski?

  Admittedly. That's my specificity. Admittedly did it pretty bad, though I would argue it wasn't entirely my fault. That said, I've worked a while now and have plenty of public code both related to and not related to web dev and could be reviewed. Unfortunately, that did not seem to matter in this case. Another time I couldn't move forward, even though I technically completed the assessment perfectly and everything worked according to the instructions because I failed to give one unit test to pass that took me out of the running. Ooh, that's a, that's a rough one. Sorry for the weighty question. I'd still like to be programming, whether it's on the web or not, but I think at this point,

• 43:48Scott Tolinski?

  I'm just tired and ready to consider looking at other professions. So, yes, I think there are a lot of things that go involved in an interview. And one thing that you can't overlook is that you might not be right for the company, or the company might not be right as well. Because companies have interesting interview process. And I've been in interviews where halfway through the interview, I'm like, If I get a job offer presented to me, I'm not going to accept it because this interview has revealed enough to me that like, I don't feel like this, this, uh, this organization has it together. Now granted, that was back when hiring was crazy, right? And you could

• 44:31Scott Tolinski?

  get a job just by looking, uh, you could Google web development and a recruiter would come to your inbox. Um, but that said, I do think this prior work is important. I think that's a big factor. It's a big factor of getting to talk with somebody, getting somebody in the door. If I get a resume, they have a really impressive GitHub, I look at their code, their code looks great. That gets you in the door, but it doesn't get you the job. Because what gets somebody the job is how well they mesh with the team, mesh with the vibe. Yeah, sure. Technical proficiency, absolutely. You pass all that stuff, that's one step down. Uh, code inside projects always looks super good, but that interview is so

• 45:14Scott Tolinski?

  important from a personality perspective, more so than a lot of things. And people don't like to think this because we're developers, right? It should just be my code, that's the end of the line, right? My code is pristine, my code rules, you should want my code. But they're not hiring your code, they're hiring you as a, as a programmer. And that is a big part of it. So not to say that your interview was bad because of something you did, I wasn't there, but just know that it is a factor of getting you in the door and it's a factor of, of putting you higher on the list. But having these things will not seal the deal no matter what.

• 45:52Wes Bos?

  Yeah. He says the reason he didn't get the job was a failed test that didn't pass. I don't, I don't think that was.

• 46:01Scott Tolinski?

  Correct, yeah.

• 46:02Wes Bos?

  That may be what they told you because it's, it's also hard to tell people, hey, uh, people, any feedback? Why didn't it work out? You know? But a lot of it is, I, I'm guarantee you if, if somebody really jived with you and, and you also had that mistake. I'm sure they're like, ah, whatever. You know, it's not that big of a deal. It's it's so much based on personality and and how you get along. And not to say that it's your personality. It's the

• 46:28Scott Tolinski?

  Right.

• 46:29Wes Bos?

  how the personalities work together, you know?

• 46:31Scott Tolinski?

  And Yeah.

• 46:32Wes Bos?

  It sucks to not get the job, but also it's a you maybe dodged a bullet of something that wouldn't have been enjoyable for you to work in.

• 46:40Scott Tolinski?

  Yes. Yeah, absolutely. And and you want to know what kind of feedback I got from Google? I don't know what kind of feedback you got from Google, but after three separate interviews, one of which was eight hours long and a trip to San Francisco, I got a one sentence email that was, you did not get the job. So, you know, not everybody is going to tell you exactly what you did wrong. Yeah.

• 47:04Wes Bos?

  When I interviewed at Google, I think their feedback was something around like the the technical, you know, just didn't. I didn't have the chops very early into my career. And I don't think they saw that I was a good enough coder or a software engineer.

• 47:22Scott Tolinski?

  They wanted me to whiteboard out HTTP requests without any sort of like libraries, prefetch, you know, before fetch existed. And I was just like, oh, this syntax is because I'm always either using a library or I'm using a framework that that bakes it in. So I was just like, ah, what did I, ah? And I don't know if that's why I didn't get the job, but it was like, it was an all day interview. And I had, what, like five or six technical interviews? I had to give a presentation with a PowerPoint to like three Googlers. Lot of work. And then you have like they like take you out for lunch, which is in itself like an interview, even though they don't tell you it's an interview.

• 47:57Wes Bos?

  They see what you do with the someone spills something and they see what you do.

• 48:02Scott Tolinski?

  Psychological experiment. Yeah. What was it for me that was like late to one of my interviews? Because the first interviewer like held me up. I wonder if that was this, I was supposed to be checking the clock for him, you know, who knows? Yeah.

• 48:14Wes Bos?

  I have a story about that type of thing is we were at the party for React Miami. They had these like little globes of drinks that were like glowing and they had cherries in them. And I was like, oh, I'm gonna take one of the globes home for one of my kids. So I took mine and I was like, I'm just gonna like take the ice out and clean it up. And then I, I was shaking it to get the ice out and didn't realize there was cherries in there. So all these cherries fell into the sink in the bathroom. And I was like, oh crap. And, and then there was like, like a bunch of people around. So I just like, I just got my hands, I scooped up the cherries and I went over to the garbage and put them in there. And some guy comes over like half in the bag.

• 48:57Wes Bos?

  He's like, dude, you're so cool with me now because you did that. Most people would have just left it for the cleaner.

• 49:03Scott Tolinski?

  Really?

• 49:03Wes Bos?

  Says a lot about your personality. And I was like, yeah, like that's, that's the kind of stuff that like, what do you do in those situations? You know, it's obviously embarrassing for me that I spelled cherries in the bathroom of this bar.

• 49:16Scott Tolinski?

  That's so embarrassing.

• 49:17Wes Bos?

  But like, just, yeah.

• 49:19Scott Tolinski?

  I don't, I don't understand the type of person who wouldn't pick that up.

• 49:23Wes Bos?

  No, no, there's a lot of people that do that type of stuff. It's the same people that don't pick up after the dog when they're, they're walking.

• 49:30Scott Tolinski?

  I empathize with anybody who's doing that type of work because that's not a lot of fun. I had to clean the bathrooms at a ski hill for several years and that sucked. So I tend to keep bathrooms very clean. If I'm making a mess with cherries, I suppose.

• 49:47Wes Bos?

  Yeah.

• 49:47Scott Tolinski?

  Yeah.

• 49:50Wes Bos?

  Oh, all right, let's move into sick picks and shameless plugs. I've got a sick pick for you today. I'm gonna pick just getting dim, warm bulbs for your house. So we have all these little kids nightlights and kids have lamps in their, in their rooms and whatever. And like a regular 60 watt equivalent, whatever the LED equivalent is, it's too bright. It's, it's absolutely brutal and I feel like it keeps our kids up longer. So I like went and found. What is the like dimmest possible bulb I can buy? I found some that are like 10 watt equivalent.

• 50:29Wes Bos?

  We gotta switch to using lumens for bulbs because we still like, we haven't had 60 watt bulbs in Canada for like 10 years. And I still think a 60 watt bulb, but like they're, they're LED, but they have a really nice warm glow to them. 2200 Kelvin and it's just makes them feel a lot better. I'm big on like lighting color as well as like lighting amount. And if you can't dim a light, then yeah, maybe go grab some, one of these bulbs.

• 50:57Scott Tolinski?

  Nice. Yeah, I wish that I could get Courtney to appreciate a dark warm bulb in the house. She got to have all the lights on full blast. And I'm just like, but it's, we gotta have a cave atmosphere here.

• 51:11Wes Bos?

  I like them on full blast when I'm working. Like I come every morning, I come into the kitchen. My wife has like a candle on and it's dark. I'm like, like turn them on. I need to see what I'm doing, but when the kids are sleeping and it needs to be a lot less bright.

• 51:26Scott Tolinski?

  I'm talking about like nine o'clock. I'm like nine o'clock. We better be like totally cave atmosphere and I can't get that. I can't get that in the household. So I wish, wish I could. I do my very best to have home assistant, like dim them all. But I think it just becomes more of a, an annoyance, a general annoyance to everyone involved.

• 51:47Wes Bos?

  Yeah, I, I often try to dim or, or brighten like 1% at a time, but you can still tell when it like, we need dimmers that will like, do it over like six minutes. So.

• 52:02Scott Tolinski?

  Yes, I do have a home assistant thing that does that for waking up. It like slowly, you know, sets them, but it is kind of a pain, you know, that I feel like that should be a default functionality just baked in. Instead of like, there's like some. Automation action you have to run and it's like kind of not super reliable.

• 52:22Wes Bos?

  Yeah.

• 52:22Scott Tolinski?

  Yeah.

• 52:23Wes Bos?

  That'd be sweet.

• 52:23Scott Tolinski?

  All right. I'm gonna sick pick stainless steel cookware. I've always been a nonstick guy. I've bought lots of nonstick cookware and buy lots because man, that stuff just doesn't last. I don't think I realized like when you're, when you're buying like nonstick, it's like set up to fail in X amount of years, no matter what.

• 52:46Wes Bos?

  Yeah, that drives me crazy.

• 52:48Scott Tolinski?

  Yeah, no matter what you do with nonstick cookware, you baby it like crazy. You never use metal utensils and you know, you, you take good care of it. No matter what, that coating always, always, always comes off. So I, I moved, we, we just, we were due for, we, it has been a long time since we upgraded or even like modified our cookware. The, the surface was coming off of just about everything. So we went straight up stainless for everything and it has taken a bit to get used to. But the best part about stainless is that even if stuff gets baked on, it's relatively easy to clean off. I found like you, you need to cook, especially, I don't know if it's all stainless or just the ones that we got.

• 53:32Scott Tolinski?

  But like you need less heat than I needed before with my, my previous pans. I don't know if that has something to do with how thick the stainless is or anything like that.

• 53:42Wes Bos?

  Yeah. The carbon steel that I use is in, in, is the same way where if you go, you crank it because you want it hot, fast. And then before you know it, it's way too hot. You know, you gotta give it a sec to sort of warm up first and do the whole thing where you draw, the water has to dance.

• 53:59Scott Tolinski?

  Yes.

• 54:00Wes Bos?

  On it and it's, there's a good TikTok, uh, steelpan.guy. Um, he's, he's hilarious. He starts all his, his TikToks off with like, this is what big chicken doesn't want you to know. And he shows how to cook in a, in a steel pan. I've not done the stainless pan yet, just yet. I've been carbon steel, but I, every now and then I'm tempted to try it. I just, I don't need any more pans.

• 54:24Scott Tolinski?

  Oh yeah, we specifically needed pans. So that was, yeah, that was the, the whole thing. But yeah, stainless steel pans. I did not even know that that was like, I gotta be real honest. I thought everything was, I mean, either you got a cast iron or you got a non-stick. I was so ignorant to the wild world of different pan options. So.

• 54:45Wes Bos?

  Yeah, there's also, there's also aluminum, which is aluminum is big in like, like commercial kitchens. You know, restaurants are big with that, but I think your steel pan is, is ideal.

• 54:57Scott Tolinski?

  Yeah, I wanted to get something that would last forever, not have to worry about some sort of coating on it.

• 55:02Wes Bos?

  All right. Shameless plugs. Check out our YouTube, youtube.com/what is it? Syntax FM?

• 55:09Scott Tolinski?

  Yes.

• 55:10Wes Bos?

  Is it? No, it's not.

• 55:12Scott Tolinski?

  Youtube.com?

• 55:13Wes Bos?

  At Syntax FM.

• 55:15Scott Tolinski?

  Yeah. What did you say?

• 55:17Wes Bos?

  I just said forward slash syntax FM. You gotta put the at in there. But hit the subscribe button. You can watch us. You can watch CJ's videos. So it's not just podcasts. We got all kinds of good stuff on there. Check it on out.

• 55:32Scott Tolinski?

  Yes. Smash that subscribe. But also leave a comment below. If you have any differing thoughts or opinions on any of the questions we asked, or if you want to ask a question yourself, head on over to syntax.fm, click that ask a potluck question button, submit your potluck question. We love to hear from you. We love your questions and keep them coming.

• 55:48Wes Bos?

  Peace.

• 55:50Scott Tolinski?

  Peace.