Mini ep 12/29/23 === Emily: [00:00:00] Happy Friday, developers. Today is December 29th, 2023, and welcome back to our roundup episode. In this special episode, we're going to go through our top three episodes of 2023. So let's get started. Transition sound: Yeah. Emily: First up, our most popular episode this year was Next. js 13 with Tim Newtkens. In this episode, we covered the big release of Next in early 2023. And in this clip, Tim talks about why React server components were developed and how the Next. js team hopes they can shape the future of rendering in React. Tim: So the thing is like in the Next. js community, like server components wasn't really a thing that people asked for a lot per se. It was mostly layouts, streaming, suspense boundaries, not waiting on get service app props to get results and things like that. So it's really like, there's these very large amount of issues and feature requests that are now solved by changing the underlying [00:01:00] architecture of Next. js. That's been our main goal with this. It's like solving the actual problems that people have a lot in Nexus apps today. So one of these is. This layouts thing, if you create like, we could have added layouts into pages, but it would have been less ideal than what you get today. The server components part is basically taking this gears of next just having server side integration. So, um, the good example here is you had to get service or props, get static props, get static pods, and all these next just specific APIs. And he's kind of influenced, uh, react team in a way where they were like, yeah, this server side thing, like we kind of proved that works, but in the end, it's not the best DX or like not the best way to compose your components. It's not a way to compose your components, right? Like you're doing it separately from your component tree. What if we move all of this data fetching logic and rendering logic that is not needed on in the browser per se. [00:02:00] So structural things in her page, for example. And move all that rendering to the server and solve many other problems in the current ecosystem around React. One of them is, , we're shipping a lot of JavaScript to the browser. Everyone will say React is quite big, but if you start looking into real apps, it's like React is quite big, but then it's still only 10 percent of your whole app or something like that. And with server components, we're basically shifting this back to. React is quite big still, unfortunately, we have some plans to get to a point where that's better, but that takes a lot of effort and time to develop a smaller bundle size basically. But now we don't have this client side code bit that you are introducing yourself. If I write an XJS app, I'm going to pull in all these libraries, stuff to format my currency or do internationalization or do data fetching or all these libraries that you're using. Cause a few years ago, NPM published that like 90 percent or so of your [00:03:00] code is actually not your code, but someone else's code you pull in through NPM and. In practice, that's like pulling in all these libraries to then do all this functionality for you. But you're also shipping into the browser and like with server components, you're shifting that away to the server, which has the spindle obviously, but then it does other benefits as well. Like it's closer to your database or it has lower latency to your database or your APIs. And this allows you to do data fetching in your components. Cause then. If your database queries are less than a few milliseconds, then you can just keep rendering components, do the data fetching there and get the result out. Send the result to the browser, which is what Server Components does, and then hydrate that without the actual need for all the static bits in that. When I say static, it's like the divs, the header, stuff like that. You can still have dynamic pieces where you get client components, which is the, if you're used to react before server components, that's basically any component.[00:04:00] Yeah. It's really exciting to see like where people will take this. Cause it allows you for way more granularity and like what you're sending to the browser, but also it now allows you to decide between like, I want to render this component or this other component, and it could be. Separate bundles. For example, you got way more commandular code splitting by default as well. Transition sound: Yeah. Emily: Our second most popular episode this year was our chat With Chris Ferdinandi , about what he sees as the future of JavaScript frameworks and the web. In this clip, He discusses what he sees as the traditional web and how we're moving away from overusing Chris: I think the poster child sentence of this podcast is like the bloated web or the transitional web. I'm flip flopping between the transitional web and the bloated web, but I like the bloated web because I think it put it, it hits that nail about what is the problem of the day and age. So I'd love to know from you, is it the transitional web or the bloated web? And why do you say the bloated web, Chris? [00:05:00] Yeah. So I think for a while now, we've been in. In the bloated web, this is something I've been talking about for a few years, like maybe four years ago or so, five, I gave this talk called the lean web where I was talking about where we are today, where we've been in this period of time, where if a little bit of JavaScript is good, a lot is even better. And so. Like we've been doing all these things in the browser with lots and lots of JavaScript that we used to rely on the server for. And in doing so, we've created this, this really fragile house of cards where JavaScript is incredibly easy to break. Like most browsers, if there's an error with your HTML or CSS, they just ignore it and move on. But because JavaScript is a scripting language, if something goes wrong, they just stop running it. And when your entire UI is rendered with JavaScript, that's really bad. JavaScript is also a lot more expensive for browsers to parse and render. It involves an extra step, and it's just a lot more [00:06:00] computationally expensive. So, like, a byte of JavaScript is Substantially worse for performance than a byte of JPEG or HTML or CSS might be. And so we found ourselves in this situation where we're just, we're throwing the worst part of the stack at the browser in increasingly large amounts. And so even though internet speeds have gotten phenomenally faster over the last decade, websites are not actually meaningfully faster. They can do cool stuff, but we're building them in a way that is. Slower, more prone to breaking, just generally like less resilient and worse. And a lot of times we're recreating stuff that we could just use the browser for or do on the server in a much more reliable and performant way. And so I talk about the transitional web. I. For a while, I was very doom and gloom about the current state of things. I actually see the pendulum finally starting to swing in the other direction. I don't think we're a hundred percent there yet, [00:07:00] but I think we're at the beginning of kind of the next big shift in how we build things for the web. And so I've been referring to that as the transitional web. Sometimes I talk about the rise and the fall of JavaScript frameworks. Not that they've fallen yet, but I see their, their use in the front end starting to diminish over the next few years. Transition sound: Yeah. Emily: And finally, for our third most popular episode this year, Kent C. Dodds returned to teach us about fully typed web applications. And here, he talks about why end to end type safety was not possible until recently. Kent: I feel like this fully typed end to end thing isn't a totally new concept, but I feel like we're at a new iteration of it right now. I guess when you're talking about end to end type safety, what do you mean specifically and why is it so valuable? Yeah. So JavaScript is a typed language. There are types in JavaScript, but there's no type checking in JavaScript itself. Certainly no runtime type checking. We've always needed to have [00:08:00] linters and now we have to type scripts and flow typed as well that. Run basically like linters. So they're still not runtime, they run statically. So they, they do this as part of the, your build process or whatever. And so because of the fact that JavaScript has no runtime type checking, we haven't really been able to get end-to-end type checking or type safety in the web for like ever until the last few years when TypeScript is kind of picked up. And the trick with typing. On the web is the web has a lot of boundaries to your application. And in the blog post, I talk about a couple of these different boundaries that we have. I have this line here where I say the secret to fully typed web apps is typing the boundaries. So you can think of a couple like parsing some JSON out of local storage, that would be a boundary. So any like IO or input output sort of thing, reading inputs from a form. So the, the DOM is another [00:09:00] boundary that we have. So both like reading things out of the DOM as well as writing and then the web fetch API also another boundary making HTTP calls, reading things from the URL, even like search parameters or if you're using some sort of param parser, that is technically a boundary also. And then we have the node side of things in JavaScript as well. So reading stuff from the file system, making database queries. And when we receive a request, parsing out the data from that request. So all of these different boundaries need to be typed because when you call a function, you, that function can have a certain signature and it's really easy to spend a day learning TypeScript to type simple functions. And then when you call it, if you call it with the wrong parameters, then you're the TypeScript compiler or the type checker that you're using is going to say, Hey, this isn't. Incorrect, or it is correct, and you don't really get that when you run into these boundaries. And so you have [00:10:00] to kind of patch that up. And the reason is because you might say, Well, I know that this file exists, and I know the contents of the file. So like, why can't TypeScript just correct. No, that or trust me or whatever, but at any moment, somebody could change the contents of that file and there's no way for your program to prevent that for a long time. And it was very difficult to get this full end to end type safety that we have because there are just so many boundaries on the web. And now that we're. We've got the technologies that we have now and typed fully end to end typed web apps is such a beautiful developer experience and makes for much more bug free applications. Transition sound: Yeah. Emily: And that's it for PodRocket in 2023. I want to thank all of our listeners for supporting us this year. We're very excited to bring you more content in 2024, and we have some great guests lined up in January. You can check out the full episodes from this episode linked in our show notes [00:11:00] or on our feed, and, if you like what you hear, for more great web development content. Have a safe and happy new year, and see you in 2024. This episode was brought to you by LogRocket. Try it for free at logrocket. com.