865: CSS Performance × Rate Limiting × Array Sort Behavior - STUMP'd

Scott and Wes challenge each other’s knowledge on everything from array sorting quirks to browser isolation types in a rapid-fire trivia format. They dive deep into performance optimizations, TypeScript type safety, and HTML best practices while uncovering surprising edge cases that every web developer should know about. Show Notes 00:00 Welcome to Syntax! 00:43 Brought to you by Sentry.io. 01:23 Question 1: Array Sort Default Behavior. 03:24 Question 2: Splitting Into Individual Words & Characters. 06:06 Question 3: NodeJS Stream Backpressure. 09:07 Question 4: Custom Middleware Rate Limiting. 13:00 Question 5: Transform Function Property Changes. 15:18 Question 6: TranslateZ & Will-Change Performance. 17:52 Question 7: Table Structure Best Practices. 20:23 Question 8: Dialog vs Div with Dialog Role. 23:21 Question 9: TypeScript Unknown vs Any & Never. 26:31 Question 10: Response Type Safety in TypeScript. 29:48 Question 11: Browser Isolation Types. 32:54 Question 12: HTML Quirks Mode Behavior. 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 on this Monday. Hasty Treat, I don't even know if we're calling these Hasty Treats anymore.

• 0:07Wes Bos?

  It's a Monday.

• 0:08Scott Tolinski?

  On this Monday episode of Syntax, we're going to be playing a game of Stumped, which is where we ask each other web development questions. We're going to do one from front end JS, back end JS, CSS, HTML, TypeScript, browser quirks. We're going to do some browser history stuff. We're going to just be asking each other these questions and hopefully they're advanced enough that we can stump each other and make each other squirm a little bit trying to get these answers. So, my name is Scott Talonsky. I'm a developer from Denver. With me as always is Wes Boss. What's up Wes?

• 0:36Wes Bos?

  Hey, excited to get stumped. These are always fun to do.

• 0:39Scott Tolinski?

  Yeah, and I'm stoked for this one. I think it's going to be really exciting. And before we get going with the game, if you are stumped by your code and bugs, well, you're going to make sure you have a tool like Sentry on your side. That's S E N T R Y dot I O, because it allows you to solve your bugs with pure visibility into your codebase. Not only that, it helps you solve your performance issues. It helps you find the bad areas of your application, the things that are slow and that are making users upset, buggy, all these things. And you can actually see the bugs happen as they happen for the user with a scrubbable video replay. So, check it out at Sentry.io/Syntax. Sign up and get two months for free using the coupon code TastyTreat. Yeah, Sentry, amazing product and happy that they're bringing this show to you today.

• 1:23Scott Tolinski?

  So, I got a question for you Wes. We're going to kick it off. Round one, round one fight. Front end JavaScript, here's your question. In JavaScript, what is the actual behavior and output when you try to use the sort method on an array of numbers without a comparison function? And perhaps why does it produce this result?

• 1:49Wes Bos?

  Oh, um, so what happens when you run a sort on an array of numbers?

• 1:58Scott Tolinski?

  Without a function as the, yeah.

• 2:01Wes Bos?

  Without, oh, without like a comparator function, which is the second or the argument to sort. It will...

• 2:09Wes Bos?

  First of all, mutate the array. So the original array will have been changed. And then the second thing is that it will, like, if you do like 1, 2, 3, 4, 5, 6, 7, all the way up to like 15, it'll be like 1, 11, 12. And then, once you get past the ones that start with 1, then it will go 2 and then 22. You know, like, it doesn't actually put them in order, is what I'm trying to say. So the reason, I actually, I don't know if I know the reason behind this, but I'm assuming it's because it converts them to strings to do the comparison. Is that right?

• 2:47Scott Tolinski?

  That's, that is absolutely correct. So it converts all elements to strings by default and sorts them into UTF-16 code units when no comparison function is provided. When numbers are converted to strings, obviously 10 comes before 2, right? Because it's in lex- lexicographic, lexical, that's another word I can't say. Lexicographic order. Did not know that word before. Interesting. Nice work. I love your deductions on that. We're all pretty much dead on, so.

• 3:22Wes Bos?

  Oh, good. Thank you. Let's talk about one that I actually needed the other day. It has to do, I guess you could do this front end or back end. But what JavaScript API would you use if you needed to split a sentence into individual words and/or individual characters? So someone gives you a sentence like, "Hello, my name is Wes Boss, comma, I love JavaScript." Exclamation mark. How would I split that sentence into individual words? And then each word into individual characters, accounting for tricky things like emojis and multiple languages?

• 4:07Scott Tolinski?

  Yeah. Yeah. You know what? I think regex is going to be involved here at some point. Obviously, you could just split with an empty space to get each word. But what, how do you use, how do you use regex here? Because it's really easy in regex to say, "Give me all the characters A through Z, capital and lowercase." How do you use that with splitting? I never had to do that. I'm not quite sure. How do you do it, Wes?

• 4:31Wes Bos?

  All right. So yeah, split is is the kind of the easiest way. And you might not run into any issues, but some like emojis are multiple characters long. And some like, I don't know if it's Chinese characters or whatever, but they are multiple characters put together and they they they appear as a single character. And then same thing with with words as well. You got to think about like if something is dashed, is it is that a single word or multiple words? And the answer to this is use the intl segmentation API. And the intl segmentation API will allow you to specify both a a locale. So you can tell it which language it is in, but also the granularity that you want.

• 5:16Wes Bos?

  So you can tell it, split it up into sentence, into word, or into grapheme, which is a something that looks like a character, but it may be made up of multiples.

• 5:29Scott Tolinski?

  INTL stuff, extremely underutilized. I think it'd be great if we could do a an episode on INTL tips and tricks, because that's not one that I knew. I feel like there's so many little things out there that you can use that for.

• 5:44Wes Bos?

  I just saw yesterday that the intl dot number format gained approval to add new formatting of currencies. So INTL number format allows you to format currencies. But there's like different ways you can format currency. Like if it's Canadian, you put CA dollar sign first. And it looks like there it's there's more flexibility added to it.

• 6:06Scott Tolinski?

  Yeah, totally. All right, here's a question for you on JavaScript backend things. And this one's about the streaming API. Okay, in Node JS, when using the stream API, explain what back pressure is. I think that's a good enough question.

• 6:25Wes Bos?

  Um, so the, the idea with a, a stream.

• 6:29Scott Tolinski?

  And I'm going to post them here. I'll post some code that you can look at. So this is some, some code about what it is. We can maybe put this up on the video. I don't know why it's not pasting correctly, but basically you have a read and write stream where you are writing to a file as the data is coming in.

• 6:47Wes Bos?

  Okay. So I'm assuming what happens here with streams is that you are sending data from one end and you are receiving it on the other. And you hope that those things are keeping up with each other.

• 7:02Wes Bos?

  And I should say, by the way, I have no idea, but I'm, I'm going to guess what this is.

• 7:06Scott Tolinski?

  Yeah.

• 7:06Wes Bos?

  And when you, when you need to do something with the data on the receiving side, like write it to file or, or parse that data, there could be a possibility where you're taking in data faster than you can deal with it. And at that point you will start to run out of memory or, or something like that. So what the question was, how do you deal with back pressure?

• 7:33Scott Tolinski?

  Um, the question is really just explain what it is.

• 7:35Wes Bos?

  Yeah. So I'm assuming that's what it is, is when there's more cars lined up at the stoplight than the road can support?

• 7:45Scott Tolinski?

  Man, for, for two answers in a row, you've said, you've claimed that you have no idea. And you've gotten it dead on, almost reading purely off of a definition here. So yes, that is correct. Back pressure occurs when the writing speed cannot keep up with the readings, reading speed without proper back pressure handling. This can lead to high memory usage, such as data chunks queuing up in memory. And so basically the way they have it as a solution here is to use a, a resume and to check to make sure that, so you're pausing the read stream. And then once the write stream has been drained, uh, the read stream can resume and can continue.

• 8:26Wes Bos?

  So. Okay. So there is a way to communicate via the stream?

• 8:32Scott Tolinski?

  Yeah, I actually posted the code. We'll, we'll have the code in the, in the show notes. But basically, yes, you're, you're saying, um, if you can't continue, pause the read for a second. Once the right is, uh, is ready, then. Whoa. Then resume the stream. Sorry, I almost knocked over my coffee. That happens a lot over here, Wes. I'm just gesticulating around over here, always knocking over my stuff.

• 8:55Wes Bos?

  That's great. Oh, cool. I want to make a example like that where, yeah, you can like essentially pause the stream while it is, it is ready to go. I like it. Good. That was a good question. Thank you.

• 9:07Scott Tolinski?

  Yeah.

• 9:08Wes Bos?

  Uh, all right. I gotta get another one. That's way too hard.

• 9:14Scott Tolinski?

  Don't know.

• 9:15Wes Bos?

  Could I, I'm not gonna ask you an answer, but I just want to laugh with you. In a high concurrency no JS application using the cluster module, explain potential race conditions and memory sharing challenges when implemented a distributed in-memory cache across worker processes.

• 9:32Scott Tolinski?

  Oh, yeah. What a question. Could you imagine being in an interview and then getting that question and just been like, I don't know. Like, you must be applying for a very specific type of role to get questions like that. So

• 9:44Wes Bos?

  Yeah.

• 9:44Scott Tolinski?

  None, nothing my UI brain can do. So.

• 9:48Wes Bos?

  The next question here is, describe a comprehensive strategy for implementing a custom middleware-based rate limit system in something like, it says Express JS, but in, in something that has a middleware in it. Hana would be a good example.

• 10:04Scott Tolinski?

  Yeah. So rate limiting, my understanding here would be that for rate limiting, you're checking like if, if too many requests are coming in per a given amount of time, then you're going to want to stop. Do you, in rate limiting, do you, do you prevent, like you say, wait, hold on, if too many are coming through? Is that what you do? Or do you, do you slow it down? I actually don't know.

• 10:29Wes Bos?

  You can do either. It's most likely you're just say, hey, you've done too many now, now stop. But you could also increase the time that a request takes every single time. And that stops someone who's entering a password once, takes. 100 milliseconds, but then the second time is 200 milliseconds.

• 10:48Scott Tolinski?

  Yeah, so basically what you're going to be doing is you have a threshold for how many requests can happen per a given amount of time. And each time a request is coming in, you're incrementing that over that given amount of time. In that given amount of time, that variable in memory, I suppose in memory is going to be storing

• 11:08Scott Tolinski?

  how many requests currently you have per that time. And then if that exceeds your limit, then you're, like you're saying, you're either slowing them down or you are blocking them entirely. But basically, yeah, you're just not, because middleware functions, like it's stepping into the request process, right? The request comes in and then you can even augment it on the response out. It's happening in the middle of that process. So if you can step in there and say, wait, hold on, first thing in the process is that request, these have been coming in too fast. Let me just slow down and block them. I had to implement something like this for people spamming, they're spamming stolen credit cards on the level up checkout phase.

• 11:48Scott Tolinski?

  Because even if I had captcha or all this stuff, you'd still get people who would just try a whole bunch or whatever. So I had to put a rate limiting of you can only try, you can only try four credit cards per hour, per account or whatever. So, you know, it's a, you don't want to block anybody who's legitimately accidentally entering their card wrong, but at the same time.

• 12:08Wes Bos?

  I have that on my, my, my rate limiting is primarily IP based. But I often will have like an entire class at like a university try to sign up. And it immediately shuts it down because within two minutes, you have 50, 100 people try to sign up for it. And that's, that's a problem with literally everything, but it's a problem where good people do things in the same way that bad people do things. But yeah, that was a great answer. I like it.

• 12:40Scott Tolinski?

  You can rate limit individual users, you could rate limit every user, you could, yeah.

• 12:45Wes Bos?

  Yeah, you can do it on a user basis, but then like if they use a VPN or they like clear their browser or they're running a script from, that doesn't have cookies. It's a hard problem to solve, but yeah, we did a whole show on that as well.

• 13:00Scott Tolinski?

  I have one for you, Wes. And this is based on a, in fact, an informative tweet that I did on using the translate and transform properties. So in the past, you could use transform to use something like translate, right? What specific translate or transform function did not become a property? Once they moved translate to a property.

• 13:28Wes Bos?

  I was actually gonna ask you this.

• 13:30Scott Tolinski?

  One of them did not become a property here.

• 13:32Wes Bos?

  One of them.

• 13:33Scott Tolinski?

  And it's not a version of it. It's not translate 3D, so to say.

• 13:36Wes Bos?

  Oh, I was gonna say like translate Z. Okay, so transform, let me think about what the possible options are, right? You have scale, you have rotate, skew, translate. It's just rotate, skew and translate, right? So is it, is it translate? No, translate did make it. That was your whole, your whole point, right?

• 14:00Scott Tolinski?

  You're forgetting one. I just want to say you're forgetting one.

• 14:03Wes Bos?

  Okay, let me think about this. You got scale, rotate, skew, translate. There's one more?

• 14:10Scott Tolinski?

  No, that you didn't say scale before.

• 14:12Wes Bos?

  Oh, I didn't say scale. Okay, so scale, rotate, skew and translate. I think the one that did not make it was translate.

• 14:20Scott Tolinski?

  Do you think the one that did not make it was translate? Okay, no, because that wasn't my example and you knew that. You already even said that once. The one that did not make it is skew. There is a scale property, a rotate property and a translate property, but no skew property.

• 14:36Wes Bos?

  Well, wait, does so Trent, is there an equivalent of translate X and Y CSS properties as well?

• 14:43Scott Tolinski?

  Well, translate can accept multiple values here. Yeah.

• 14:47Wes Bos?

  Okay, but if you did want to just change one of them, you'd use a variable. Okay. Oh, man, skew, skew is my favorite.

• 14:54Scott Tolinski?

  Yeah, I don't know why. And in fact, a promise quote tweeted my thing, giving some extra context. And I replied to him saying, what's up with skew not making the jump? And did not respond, so I gotta, I gotta get that answer from somebody.

• 15:08Wes Bos?

  That's deep down. Don't ask questions you don't want answers to, Scott.

• 15:11Scott Tolinski?

  Exactly. I'm shaking the boat here, rocking the boat.

• 15:17Wes Bos?

  Oh, that's great. All right. Here's my CSS question for you. Explain the potential rendering benefits and downsides to using translate z0 or will change transform in CSS. Maybe even just narrow that down to will change. What are the potential upsides and downsides to using it?

• 15:39Scott Tolinski?

  Yeah, I don't know if will change explicitly implements the GPU or not, but I know translate with the Z axis does put your transforms onto the GPU, which can be advantageous, especially if you're wanting smoother animations. Will change is an interesting property because it kind of preps the browser to know that this item will be animating and therefore it's able to potentially make it a smoother experience. Now, will change, my understanding, and this could be right or wrong. I'm going to say I don't know explicitly. I have looked this up at some point. My understanding is that will change becomes a problem if too many things are listed as will change because the browser has to keep track

• 16:23Scott Tolinski?

  of all of the things that will change. And if you have a billion things that will change, then that can become a problem and can slow down your site. I do believe will change will may, I don't know if will change does put it on the GPU or not. I don't want to say yes or no to that because I don't know. Actually, I'll go for it. I'll say it does put it on the GPU.

• 16:43Wes Bos?

  That's good. Yes, you're right. So CSS will change hints to the browser how an element is expected to change. So you could say will change transform, will change opacity, will change scroll position, and it hints to the browser, hey, this thing will change. However, like you said, it's intended to be used as a last resort because the browser already tries to do this.

• 17:10Scott Tolinski?

  Yes.

• 17:11Wes Bos?

  And there are some downsides, like it creates its own stacking context. So if you're doing any like blends with something that is behind an element, then you can goof up the stacking context or background. I think a background blur or something like that in CSS can, I had that issue myself where it wasn't blending properly in Safari.

• 17:33Scott Tolinski?

  So it was will change, huh?

• 17:35Wes Bos?

  Yeah, so it's something as to be used as a last resort and it's usually just something you just throw it in there and see if it changes.

• 17:44Scott Tolinski?

  Yeah.

• 17:44Wes Bos?

  Measure and then if not, then maybe you want to take that out because otherwise, once you make everything faster, nothing is faster.

• 17:53Scott Tolinski?

  That's right. That is right. Uh, here's an HTML question for you. This is a fun one here.

• 18:03Scott Tolinski?

  This is a fun one about HTML tables, which, uh, gotta love HTML tables. What is the difference and why might this cause unexpected behavior between a table with an immediate child as a table row and then table data verse a table with a table body element and then the table row table.

• 18:25Wes Bos?

  So the difference between a table with an immediate table row versus a table with a table body and then a table row?

• 18:34Scott Tolinski?

  Correct.

• 18:37Wes Bos?

  Oh, I don't know. What, what? Sorry. What the question was, what's the difference? Or like, what's the downside?

• 18:43Scott Tolinski?

  What's the unexpected issue that might happen by having by, let's just say, what's the unexpected situation that will happen from writing the first one without the table body? Like, let's say you didn't write a table body. What is an unexpected situation that could arise from that?

• 19:00Wes Bos?

  Um, something to do with like call span and lining up with the table headers.

• 19:08Scott Tolinski?

  It's not, but it's interesting nonetheless. So the unexpected behavior is that the browser automatically inserts a table body. So if you don't have a table body, it automatically inserts one, meaning that the HTML that you author will not match the HTML in your code, meaning that if, let's say you looked at the code and were for some reason saying, I'll do an immediate child of the table, uh, and expecting that to target the table row because that's what it looks like. Well, it'd actually be targeting the table body, which isn't in your code and does, does not exist in your code, but does exist when it's rendered into the body.

• 19:49Wes Bos?

  But what code would you write that would, like, I'm assuming both CSS and JavaScript would know about the body because the browser injects a body?

• 20:00Scott Tolinski?

  I put just a CSS, quick little CSS thing where you could have like an immediate child selector.

• 20:06Wes Bos?

  Immediate child selector? You're saying that you would assume that your direct child descender would work?

• 20:13Scott Tolinski?

  Basically, the end result is that the HTML in the browser does not match the HTML in your code.

• 20:19Wes Bos?

  Yeah. I did not know that. That's like, that's my next question. I was about to tell you, but I'm gonna, I'm gonna tell you. Name an HTML element that does not need to be closed.

• 20:31Scott Tolinski?

  List item.

• 20:32Wes Bos?

  And, ah, I got it. Okay, give me a harder one. Hold on.

• 20:36Scott Tolinski?

  I know that. That's what I, in fact, the moment that you said that, I was prepping myself for that exact question. So I had it, I had it primed. I had a will change answer in my head.

• 20:46Wes Bos?

  Isn't that weird? So you don't need to close your list items, folks?

• 20:49Scott Tolinski?

  No.

• 20:49Wes Bos?

  Don't waste your time.

• 20:54Wes Bos?

  Oh, all right. Here's my actual question.

• 20:58Scott Tolinski?

  Oh, it doesn't count because I got it right. All right.

• 20:59Wes Bos?

  Describe the precise semantic and accessible implications of using dialogue versus creating a modal with a div and a role of dialogue. So like, maybe not the semantic or whatever, but basically, why would you use a dialogue instead of a div with a role of dialogue?

• 21:20Scott Tolinski?

  Yeah, dialogue does some neat stuff. First and foremost, when you open a dialogue, it captures your mouse and keyboard. So if I, if I open a dialogue and then I, I start typing, it's gonna, or even like tab around, it's gonna immediately select the next thing inside of the dialogue. So that's a big one. Also, escape key by default will close that bad boy. So inherently makes it more accessible in those ways, right? Giving you that keyboard support. Are you looking for more things here?

• 21:52Wes Bos?

  Uh, that's, that's good. I think that's good. I, my answer here has a couple more things. Actually, I didn't know this restores focus to the element that opened the modal.

• 22:04Scott Tolinski?

  Yep. When you close it.

• 22:05Wes Bos?

  I didn't know that. So if you click a button, open a modal, tab around, submit a form.

• 22:11Scott Tolinski?

  Or hit escape.

• 22:12Wes Bos?

  And then hit escape and it goes back to focusing that modal. Other things is dialogue boxes are rendered to the top layer. So you don't have to fuss with Z and X or fuss with like appending it to the end of the DOM. You can use absolute positioning without having to, to worry about any of that.

• 22:30Scott Tolinski?

  But then you do have to fuss with anchor positioning, which is not fully supported.

• 22:35Wes Bos?

  And then there's backdrop. Um, you can animate backdrop in, which is, yeah, there's a lot of good stuff.

• 22:42Scott Tolinski?

  I love backdrop. Backdrop is one of those things I hate implementing.

• 22:46Wes Bos?

  You can open them. No, you can't open them with HTML, but you can close them with HTML.

• 22:50Scott Tolinski?

  Soon though, you can open them with HTML with invokes.

• 22:56Wes Bos?

  Yes.

• 22:56Scott Tolinski?

  Yes. So soon.

• 22:58Wes Bos?

  I'm excited for that. You can, you can close them with a form submit, which is really funny. What's, what's the form submit?

• 23:05Scott Tolinski?

  The form submit is form method. It is, I think it's just, is it just dialogue? I think it might just be dialogue.

• 23:13Wes Bos?

  Yeah. There's a get and post and then just dialogue.

• 23:17Scott Tolinski?

  Yeah. I talked about this stuff in my talks. It was good. Yeah.

• 23:20Wes Bos?

  There you go.

• 23:21Scott Tolinski?

  All right. Here's a question for TypeScript for you.

• 23:25Wes Bos?

  Okay.

• 23:25Scott Tolinski?

  This one, I feel like you will, you will nail this one, but I'm going to ask it to you anyways, because I do think this is good for our audience. In TypeScript, please explain the difference between unknown and any. Describe a real world scenario where using unknown would be safer than any, but never would be too restrictive.

• 23:50Wes Bos?

  The difference between unknown and any in TypeScript is that when you have a type that is any, it literally can be any. So often you'll have a function where you don't know what is going to be passed in. And at that point, you can either say it will be of any type, or it will be of an unknown type. And the thing about TypeScript is it lets you do anything with any type, meaning that if you were to try and add one to an any type, it's allowed. It's any type. If you were to try to do some string stuff, capitalize to uppercase on an any type, it's allowed. It's any type.

• 24:33Wes Bos?

  With unknown, which is almost always what you want, the unknown type makes you first type, narrow it down to the type before you go ahead and use it. So if, if you want to add a number to it, you're not allowed to do anything with an unknown until you first type narrow, check that it is a number. And then once you're within the narrow type of a number, then you can go ahead and start doing number stuff with it. So if you do not know what is coming into your function and you want to do something with that value, it is almost always better to make it an unknown, explicitly narrow it down inside of your logic and then go ahead and use it.

• 25:17Scott Tolinski?

  Yeah, I love it. I think that's great. I think that's perfect. Nice work.

• 25:22Wes Bos?

  Beautiful. Thank you.

• 25:23Scott Tolinski?

  I would say though, here's, here's an aside before we move on to the next question. I just looked up invokes and to what the status of them are. They are available behind a flag in Chrome, Safari and Edge. Oh no, in Firefox, not Edge. That they're behind a flag in all three of the major Chrome, Safari and Firefox invokes.

• 25:44Wes Bos?

  Wow.

• 25:45Scott Tolinski?

  Incredible. They like, people didn't even know what they were a couple of months ago.

• 25:49Wes Bos?

  Is, is there a list of the possible invoker commands?

• 25:54Scott Tolinski?

  Yes, there is. And it's, it's so far, it's going to be mostly modal stuff. So that is like, the, the, the commands that are like stopping asserting an audio player and stuff are not involved in that.

• 26:05Wes Bos?

  Yeah.

• 26:06Scott Tolinski?

  So it is.

• 26:07Wes Bos?

  Get that eventually.

• 26:08Scott Tolinski?

  Yeah. Right now it is, I believe, just the, you know, toggle, pop over, toggle, whatever.

• 26:14Wes Bos?

  Yeah.

• 26:14Scott Tolinski?

  Yeah.

• 26:16Wes Bos?

  I even wonder if you'll be able to like.

• 26:19Wes Bos?

  Register custom invokers. I know that kind of defeats the purpose.

• 26:22Scott Tolinski?

  No, give me, give me that, yeah.

• 26:26Wes Bos?

  Write a little JavaScript to not have to write JavaScript.

• 26:29Scott Tolinski?

  You're right, exactly, yeah.

• 26:31Wes Bos?

  In TypeScript, you have a fetch request with the default TypeScript types, the browser types for a fetch request.

• 26:40Scott Tolinski?

  Okay.

• 26:40Wes Bos?

  When you fetch something and then you response dot JSON it, right? If you want it to be of a specific type, like, let's say it's a syntax podcast episode, and we have a type of show that has a title and MP3 URL, all that stuff. So if you were to fetch it, why is it not a good idea to use the as show on the end? Or why cannot, why can't you pass a generic to JSON saying this is the type of, of what it is? Not to say that we don't do that, but.

• 27:17Scott Tolinski?

  For the fetch itself?

• 27:19Wes Bos?

  Yes.

• 27:20Scott Tolinski?

  Because it may fail and it may not return a show.

• 27:27Wes Bos?

  Which, which one? So if it fails, that's not a, that is not covered because the fetch would just cover the happy path, right? That the catch would, would cover the failure of it.

• 27:41Scott Tolinski?

  Yeah, but I guess, well, because you have to, you have to get the two JSON. You have to, are you talking about asserting the return of two JSON?

• 27:50Wes Bos?

  Yes, exactly. That's what I'm talking about.

• 27:55Scott Tolinski?

  Because of serialization of data types? Is that a tree worth barking down, barking up?

• 28:05Wes Bos?

  No.

• 28:06Scott Tolinski?

  Yeah, I don't know. Well, I guess that could be though, because a show type from the database is going to have different data types than what you parse from JSON.

• 28:14Wes Bos?

  No, I'm saying like, if you, if you know what type is coming back from an API,

• 28:21Wes Bos?

  you think, oh, I would just like to have a generic on J, on fetch. So I can tell it what is coming back. And there's a reason why TypeScript doesn't have that in their API.

• 28:33Scott Tolinski?

  Do it to me.

• 28:34Wes Bos?

  Okay, it's because you don't know. You think you know that it's going to return a show, but what happens if the data being returned is not of that specific type, right?

• 28:47Scott Tolinski?

  You just, yeah.

• 28:47Wes Bos?

  So using a generic or casting it with as is just telling TypeScript that it is of this specific type. And of course, we all do that in some cases where you're like, ah, it's gonna be that. But the proper way would be to narrow the type and actually check that the shape of your data that has come back from the API is actually what you're expecting. So whether that's via validation step or simply just checking for the properties that are in there, it looks like, looks like a duck and walks like a duck.

• 29:19Scott Tolinski?

  Might be a good use case for ZOD, something like that, right?

• 29:23Wes Bos?

  Exactly.

• 29:23Scott Tolinski?

  Validating your data and then you can get those types straight about it, straight out of it as well. Make sure that, yeah, okay, cool.

• 29:29Wes Bos?

  The, what I really like about Tansack Start, I was trying it out, is that all of their server functions have like a validation middleware where you can use ZOD or something like that in it. So you know that the data coming in is of the specific type.

• 29:47Scott Tolinski?

  Yeah. Oh, man, this one's interesting. Okay, this is a browser question for you, Wes. What are the differences between site isolation, process isolation, and origin isolation in modern browsers?

• 30:03Wes Bos?

  Site isolation, origin isolation, and what?

• 30:11Scott Tolinski?

  And

• 30:13Wes Bos?

  Process?

• 30:13Scott Tolinski?

  Process isolation.

• 30:16Wes Bos?

  Oh, man.

• 30:17Scott Tolinski?

  Site process origin.

• 30:19Wes Bos?

  That's a great question. So isolation, I assuming, is whether or not data is accessible to other things. Is, am I on the right?

• 30:33Scott Tolinski?

  Yeah.

• 30:33Wes Bos?

  The right thing, okay.

• 30:34Scott Tolinski?

  You could think of it as like a process for the browser, yeah.

• 30:37Wes Bos?

  Okay. And there's different spaces in which those things can be isolated, right? Like an origin, immediately I go to, like an origin is like a domain name, right? Syntax.fm, the data is isolated to the origin. That's something like local storage, right? It's shared amongst multiple

• 30:58Wes Bos?

  Tabs in multiple browsers of the same thing. So I'm gonna say origin is domain based. Process would be like the difference between multiple tabs of the same website in the same browser. And then site isolation.

• 31:16Wes Bos?

  Like a subdomain, maybe?

• 31:19Scott Tolinski?

  So I think you're you're close. So the site is one process per the website. So I'd imagine that's per domain. Where the origin isolation, it takes into account protocol, domain and port. Where the site I don't believe does. Let me even confirm that.

• 31:34Wes Bos?

  Oh, protocol, domain and port.

• 31:36Scott Tolinski?

  Yes.

• 31:37Wes Bos?

  Yeah, the port is an interesting one. Because if you have like a local host, sometimes I think it's like local storage is shared between ports. But but not domain.

• 31:50Scott Tolinski?

  Yep. And so site, the definition for that is it groups by effective top level domain. So mail.google.com and drive.google.com are considered to be the same site. However, evil.com and evil.co.uk, these are not my domains, would be different.

• 32:10Wes Bos?

  Oh.

• 32:10Scott Tolinski?

  So that's why that's why when you do something like a WWW dot, it can utilize the same cookies as the other subdomains, but not from Apex to subdomain. Now, here's an interesting one, a little bonus. Do you know the relevant HTTP headers to modify these?

• 32:31Wes Bos?

  No.

• 32:33Scott Tolinski?

  Yeah. Cross origin opener policy or coop, cross origin embeder policy and cross origin resource policy. I don't know any of those. Other cores things for people who really want to go nerdy into cores.

• 32:48Wes Bos?

  Wow. That I had no idea about that. That's that was a good one. All right. Explain what quirks mode is in HTML and name one of the possible things that will happen when the browser is running in quirks mode.

• 33:06Scott Tolinski?

  Man, I haven't had to think about quirks mode in a long time. This is something I know I should know and I'm gonna, it's something I just haven't had to access in a long time in my brain. Let's think quirks mode quirks mode is enabled when like you do things like omit a doc type. Would that enable quirks mode?

• 33:26Wes Bos?

  That's exactly how you enable quirks mode. Yes.

• 33:29Scott Tolinski?

  What is quirks mode? What does quirks mode do?

• 33:32Wes Bos?

  Yeah, if you put a document into quirks mode, what would you expect to happen?

• 33:38Scott Tolinski?

  Ah, that I couldn't tell you. I know it has something to do with which APIs are available, but I don't know. I don't know anything about it.

• 33:46Wes Bos?

  It's inconsistent margin and padding, different handling of table cell sizing, unpredictable float and positioning behaviors, non-standard CSS implementations, inconsistent width and height calculations, different handling of percentage-based measurements. This is basically like before the browsers got together and like standardized on a lot of how these things should work. There was older doc types and those older doc types dictate to the browser how it should work and other poor people that have to maintain these old quirks mode. So now HTML5 or doc type HTML is, it puts you out of quirks mode, right?

• 34:31Wes Bos?

  So if you ever forget a doc type, you're going to get a little message in your console that says, operating in quirks mode.

• 34:37Scott Tolinski?

  I like how you said now, when like that came out in like 2011.

• 34:42Wes Bos?

  Yeah.

• 34:44Wes Bos?

  It's been this way for like 15 years. Yeah.

• 34:46Scott Tolinski?

  Yeah.

• 34:47Wes Bos?

  Oh, that's wild that someone has to keep quirks mode code running somewhere. We should, I want to have the guy on who's working on the Ladybird browser.

• 34:57Scott Tolinski?

  Yes, me too. I think about Ladybird all the time.

• 35:00Wes Bos?

  Is he going to support quirks mode? Probably not.

• 35:02Scott Tolinski?

  Let's hope not. I did see that they responded to my tweet about transforms that that is already supported in Ladybird. So it seems like Ladybird is cruising on APIs that they've supported.

• 35:13Wes Bos?

  That's really interesting. Cool. All right. That's it for today. Hopefully you enjoyed that. Anything else to add or should we wrap it up?

• 35:20Scott Tolinski?

  Nothing. I got nothing. How many of these questions did you get stumped by? Do you have any questions for us in later episodes of Stump? Do you want to look? Maybe we can get a little stumped going in the audience and people can just post questions into the comments. So if you have any questions, you want to stump people, you think you know something, or maybe you want to stump us or whatever, leave those questions down below. We would love to try to answer them. That'd be a lot of fun.

• 35:43Wes Bos?

  All right. Peace.

• 35:45Scott Tolinski?

  Peace.