Dante's Inferno of fullstack development with James Quick === Chris: [00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket provides AI first session replay and analytics, which surface the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it free at LogRocket. com. I'm Chris, and today we have James Quick, JavaScript developer, speaker, and teacher here to talk about his js talk, Dante's Inferno of Full Stack Development. Welcome to the show, James. James: Hey, thanks for having me. Chris: Yeah, for sure. So a couple of questions there before we start. ~Um, ~so I watched your talk and I did realize that we were both Dan Brown fans. ~Um, I read~ some of my favorites were like,~ um,~ Digital Fortress, Deception Point, like ~way, ~way before, like, Uh, Inferno, I think Inferno is like where I stopped. Um, but yeah, so I saw that. And then another question, ~do you, do you, ~do you speak French? Like actually, James: ~Uh,~ so ~first or~ just first comment on Dan Brown. So that category of book I've read probably 100 books and like the archaeological thriller, It teaches some history, although [00:01:00] it's fictional, but it has some ~like, ~real core to it. That sort of stuff I'm obsessed with, and I'm reading the 23rd book in another series right now, which is wild. ~Um, ~anyway, so that's like a little personal note about me. And then,~ um, uh, ~the second question, what was the second thing you said? Chris: ~um, ~French, I noticed you came out, so I thought I had like my audio switched to ~like ~a different language cause you sounded so good. And I was like, Oh wait. And then you switched back to English. And I was like,~ Whoa,~ Whoa, Whoa. James: Yeah. ~Um, ~so ~I, ~I've spoken a pretty good amount of Spanish for a long time since high school. A friend of mine was from Argentina and learned Spanish in his house. And then I've been obsessed with languages since. ~And ~about two years ago, I started doing French on Duolingo and have actually been to Paris three times in the last year and a half or so. So I've gotten to try to use it there. ~Yeah. ~I speak some French, that's about as far as it goes. That was a couple of sentences that I got to rehearse several times before going on stage ~and and try to ~try to do it appropriately. But I'm a big language nerd. So language and history, ~I guess, ~are ~two or ~two of my big things. Chris: That's awesome. ~I mean, ~it's a good thing to have since you travel a lot ~for, ~for conferences as well. So that was convincing to me to like someone that doesn't know it, [00:02:00] you sounded pretty convincing. And I was actually. In shot to be honest. James: thank you. Chris: so yeah, let's get into it. So Dante's Inferno of full stack development. I know like people nowadays when they hear full stack development, it's actually just. It's very overwhelming because there's just so much things going on. Can we ~kind of ~talk about what are the key challenges that make full stack development so complex and then with ~like the, ~the constant evolution of the front end space as well, like how do you even keep up to date with what's happening there? James: yeah. So full stack ~is ~is in a really interesting state now, because I think we've blurred those lines. And you almost have to be a full stack developer to learn modern frameworks. And if we go back to ~kind of ~when front end and back end was more clearly defined,~ right,~ we have a back end, no JS, if we stay in the JavaScript ecosystem, have a node JS back end. You have API's. I think we've got some notes in here to talk about spas and a little bit, but you could have this really clear delineation of like back end developer working on API's doing database calls. And then you have your front end developer who could be doing a react front end, for example, and then making those API [00:03:00] calls to the back end. And there was a ~clear, ~clear delineation. When you look at ~like ~these modern hybrid frameworks, Next. js is probably the biggest name. Astro is one of my favorite frameworks and has full stack capabilities as well. And there's ~several, ~several others, but to be able ~to, ~to follow a tutorial in Next. js now with server components, you're thrown immediately into I'm writing react, but I'm running code on the server. And then I can get out of the server if I want to, and only run on the client and tracking when and where code runs in a framework like Next. js is overwhelming, because you have to really understand that. And then tracking the performance implications and just the application implications of when and where and how you run that code based on ~all the ~all the options that they give you, I think is part of the reason that it's like ~really, ~really overwhelming. And I think ~I ~I'm in a fortunate position. So I do content like I do YouTube videos, that means that I have the ability to ~kind of ~tinker more than most people, right? ~Like if you ~if you're a software [00:04:00] engineer, you work 40 hours a week, and you're whatever tech stack you have at work, that's the thing that you do 40 hours a week. For me, the downside is I don't get that ~like ~real world engineering experience on a regular basis. But what I do get is this ability to ~kind of ~jump around and try new things. And so that's, that's part of the answer to your question about how do I stay on top of stuff? One is I just follow things that I'm interested in. I'm active on Twitter. I watch other people's YouTube videos. I read articles. Daily. dev ~is, ~is a favorite ~like ~extension and website of mine that just aggregates articles that are really relevant for me. And so I just try to ~like, ~stay a part of the conversation. I listen to podcasts. This is one that I listened to fairly frequently as well. And it's one of those things where I hear people talk about certain topics. enough to then ~I ~eventually I get to the point of like, okay, it's my turn ~to, ~to try this thing out or to do a YouTube video on this thing, or maybe incorporate it into a project that I'm working on, etc. So I have more flexibility, I would say than ~like ~your traditional software engineer. And I enjoy that I enjoy bounce around and kind of learning new things [00:05:00] and ~kind of ~seeing where the trends are going across framework to framework. Chris: Yeah. I think that's something I admire just being able to~ kind of, I mean, ~effectively just do what you want. ~Right. ~And just play with everything ~you, ~you ever wanted to. ~Like, ~I think one thing you said about we're blurring the lines between front end and back end. ~Um, ~that resonates with me. Cause I remember when we first started getting into like kind of merging the two, I would always get like windows not defined or something ~because, ~because it's on the server and I was like,~ well,~ how is this possible? Is this rendering on the server? I have no idea. And that was like one of the ~most, um, pain, ~biggest pain points for me. So how did we even get here? Can we talk about like the evolution? From just like static HTML to where we are now. And ~like, ~what do you consider like these monumental moments? Because it's ~kind of ~crazy. Like what we're talking about with ~like ~the server components and everything. James: Yep. ~And, ~and to ~kind of, um, ~tie into the title of the talk. So the title of the talk was ~Dante's, uh, Inferno of the Nine, or like ~Dante's Inferno of Void Development,~ um, ~Nine Levels of Hell, or whatever it is. ~And, um. ~The idea is that it looks like we're just kind of circling around and what we think best practices are. So I say that to go back through history now of ~like, ~we started with [00:06:00] websites and like the 1990s, CSS. And then at some point, we got to the point where it's like, Hey, we could add some interaction to this with JavaScript. And then we did that for a while. And then it got to the point where it's like, Oh, we could actually add a server to this ~and like, ~and basically use the server to generate these HTML files as an example, or markup in general. And that kind of introduced this idea of server side rendering, not that different, like 20 years ago, or 15 years ago to really the core of what we do today. And so what that means, I always go back to ~like ~the blog example, I think that's the one that kind of transcends all these different methodologies ~is.~ Let's say you navigate to a website, you go to slash blog slash one, and I want to view that article with server side rendering, it's going to send that request to the server, the server is going to take that ID of one, it's going to query for that blog record in the database, it's going to get that back, and it's going to use Some sort of templating language to then send that back to the browser and actually render that to the [00:07:00] screen and ~that, um, ~that was great. The, ~the,~ the main issue that people had, I think, or like the reason that spas came out was to solve one problem where we look at the performance of that. And ~there's, ~there's one specific performance application that I think is the biggest indicator leading to spas. And that is the second page navigation. So let's say you go to a ~first page on the ~first page on the index page, you have ~like ~a nav bar, and it has links up there that nav bars on every single page, you go to the end, maybe you have a sidebar to like, here's an ebook that I created, like whatever. And then you click on a blog article. And the blog content is different. But the nav bar and the side nav are the exact same things. But you're making this full request back to the server to load a full HTML page or like markup. And so you start to look at like, Oh,~ well,~ what if we could just pick and choose which pieces we needed to refresh. And that's kind of the idea of like where single page applications come from. And basically the logic, we replace the logic of doing a full page refresh by sending a bunch of JavaScript to the browser to handle that for you. [00:08:00] So now, instead of making this full page refresh, you are using JavaScript to just swap out the content that you need to only that main piece of content, for example. And you do that going back to what we said earlier, traditionally with making like HTTP requests to your back end. So now your back end instead of serving HTML, mostly is responding back with JSON. And then inside of React or Angular going back further with Ember and Those sort of things, you make that request, you get back ~the ~the JSON object, and then you convert that to something that can display on the screen. So now you've solved that issue of that second page is faster now, because you've already loaded like everything that you need on the front end, the only thing that you're doing on the second page that you go to is you're querying or ~like ~requesting data from the back end through an API, you're not sending all the markup, You're not sending the markup for the header or the nav bar. You're not sending it for the side nav. You're not sending it ~for the foot ~for the footer. You're just sending [00:09:00] back the data that you need. And what's really funny about that is ~we, ~we had server side rendering, which did a lot of things really well. And we specifically wanted to solve this challenge of like, how do we have a more performant second page without doing full page refreshes? And so we kind of solved that with single page apps, but then we introduced this concept that had already kind of been solved for us, which is the first page load. And so because we're loading all this JavaScript for the framework itself, and for any logic that we might need, whether or not we use it, we now introduce the first page performance issue, which is that thing is going to take longer to load than it did previously. And I think this is ~kind of ~a theme in this is like, as we go, we recognize a problem, we solve it, and then we ~kind of ~break something that already existed. And a lot of people have very strong opinions about the state of web development and make memes about it of ~like, we've ~we're just continuing to solve problems that we've created ourselves. And I think to a certain extent, ~it's ~it's very true. [00:10:00] Yeah, I'll pause before we go on to like next step. If you want to ask anything about that. Chris: ~Yeah, I'll just, I mean, ~we kind of covered the next question, which is basically the pros and cons of spas, but I'll ~kind of ~dig in a little bit more on that. ~Um, but yeah, I'll, I'll kind of just respond to what you just mentioned and then we can kind of just keep going. Um, ~so you're, you talked about,~ uh,~ basically how we made the. ~The ~first load now bigger because now we have to load all this JavaScript. ~Um, ~and I remember my time, I think I came into a development around the era of spas and I ~kind of, ~to me it was like, okay, wow, this is cutting edge. It feels very fast. If I click everything navigated like instantly, maybe there's some spinners or whatever. But then I remembered that. Bundlers came into play and we talked about like code splitting. ~That's how we, ~that's how we solve this problem of like the first, the first page load or whatever. ~Um, ~so I guess ~like~ in your perspective, as far as ~like~ spas go, ~what do you consider yourself, like, ~what do you consider ~like ~are the biggest pros? It could have been something you mentioned already. ~Um, ~and what do you also consider ~like. ~The biggest cons as well. James: ~I think ~I think the idea of avoiding that full page refresh is one of the biggest benefits from a user experience or just user perspective. And I think it's something ~we don't want, ~[00:11:00] we desperately don't want to get rid of today. Like ~we~ we've changed, we've moved away a lot from how spas traditionally work. But one thing that we haven't wanted to move away from myself is having a full page refresh, like when we have an application on a blog, and we had a comment to that blog, we don't want to refresh the page and scroll back up to the top, we want to see that comment just appear right there. I think that's something that ~like, just ~drastically changed the way we look at building user experiences. And ~that's, ~that's the thing that we don't want to sacrifice at all. So I think from an interactive standpoint, we did a lot more with building in functionality with frameworks to drive interaction, we did a lot more for having that be. perceived better ~as ~from a user's perspective, because it just looks more natural, it looks faster, blah, blah, blah. Downsides of this mentioned ~kind of ~that first page load. And there's some things that can help with that. The other thing that gets impacted is SEO, that's ~a big, big indicator, or ~a ~big, ~big driver ~of kind ~of the next step that we'll talk about in a minute. So SEO ~there, ~I think there's still ~like, ~I don't know the official thing here. I think there's still mixed results on how well crawlers and bots and [00:12:00] stuff handle spa frameworks for SEO purposes. And ~I hear ~I hear mixed things. I hear like, oh, it's not an issue anymore. And I hear people say ~like, ~there's still some concerns around that. But the idea is ~like ~as a crawler, or a bot makes a request to your site, it then has to load and run all of that JavaScript to actually get a clear view of what all the different content is on there to then be able to index. And so because of that you were hurting your SEO because it wasn't just right there available ~to ~to it if it was server side rendered all that markup is generated on the server sent back to the browser or the bot or whatever it has everything it needs to make the decision on how to index and what information etc. And the last thing ~I think and this is ~I kind of joke that this is the most evil thing that ever got introduced into web development and it's still probably One of the issues that we try to fix the most today is the idea of the loading spinner. And so ~we, I kind of said like, ~we go from page to page or like we do one thing and it triggers some action. We make a request to the backend, we get back [00:13:00] data, we swap it in, we do whatever. So much of those interactions have loaders first. ~Like ~while that thing is happening, show a loader to show that something's happening and then display the new data. In addition to like those interactions, that first page load has a lot of that too, because you do authentication on the front end. If you're having to check if the user is logged in on the client, by doing a few different options, you have no choice, but to just show a loading state until that thing is finished, because you don't know on the server necessarily, if that user is actually authenticated. So the loading indicator, I think is actually one of the biggest things that frameworks and methodologies are still trying to solve today is how do we get rid of that and jumping ahead a little too far like server components baked in a next yes for example using suspense boundaries actually have a built in mechanism to support that like they will show a loading indicator by default until you stream in content we'll get to that and talk about it more so it's [00:14:00] still to this day like one of the things that I think frameworks are tackling the most is how do we replace the loading indicators as much as we can. And then if and when we need it, which is inevitable, how do we make that a good developer and user experience? Chris: Exactly. I agree. I know when I go to my banking site, I see about like 500 loading spinners waiting for my transactions to load and everything. And I feel like it's been like that for so long. I've ~kind of ~just ~like ~acclimated to that experience. It just actually doesn't bother me anymore. I'm just like, okay, at least I know it's doing something hopefully. ~Um, ~but there is a threshold to my patience on ~like, ~if nothing loads and I'll. Probably refresh or something. So ~that ~that's a good segue into the next methodology. So let's talk about static site generators. So we just talked about spas. Let's talk about static site generators, like Gatsby. And how does that actually change everything in the landscape of web development? And what are the main benefits over just like traditional like server side rendering? James: Yeah. So if we go back to like downside of spas, we have loading indicators, we have SEO issues. And so we look at a lot of [00:15:00] examples, a lot of sites and blogs are the easiest thing. Like it's the most relatable thing. So you have a blog with a single page application framework,~ you're, ~ you're re querying all this data from the server, which then queries from the database every time you go to that page. But the reality is blog content doesn't update very all like, typically, the workflow is I create the blog, it's done, it lives there, and it never changes. So you kind of look at ~like, ~we're wasting all these requests to the server for that information. And then the server is wasting all these requests to the database to get the same exact thing every time. So static site generators come in and say ~like, ~Hey, we're going to be building, we're going to be querying this data anyway, why don't we do that at build time? Why don't we use that to go ahead and generate HTML pages. And then we can just have them live on a CDN somewhere ~like ~replicated across the world. And that way when people hit these blog posts, they can We're no longer having to go to the database. [00:16:00] Like we only do it once during build time. And then now we have these pages that from a bot and crawler perspective, already has all the information. Cause it's just static HTML that we need to do SEO. So SEO is solved from a performance perspective for those pages. It's just, it's a page that's loaded from a CDN that has, we'll get to hydration in a second, but ~like, ~Just as minimal as it could be where we're just going to load that. So that's super performant. And then also in comparison to more traditional SSR, you're saving those requests. You're also like more secure because you're not having to protect API endpoints that you're then requesting and may or may not be checking JWTs and like all these things. It's just a file that's generated at build time and sits on the CDN. So there's really a lot with,~ um,~ static site generators that were really a game changer. And you mentioned Gatsby, that was ~kind of ~my gateway to static site generators. That was the thing at the time, four or five years ago, where people every day on Twitter, I rebuilt my site with Gatsby. It's amazing. And it's [00:17:00] so fast and it's blah, blah, blah. And that was one of those situations where I heard people talk about it enough to me get to the point,~ like,~ okay, I need to go try this out. I'm going to move my blog to Gatsby. I'm going to be like one of the people. And do the thing that we all do, which is try a new framework,~ um,~ over and over again and did that and ~had a, ~had a pretty good experience. ~Um, I would, ~Gatsby is not something that's top of mind for me now for different reasons, but Gatsby at the time was really that gateway to me. And I think for a lot of people for mainstream, like static site generation. Chris: Awesome. Yeah. I haven't used Gatsby in a hot minute. I know it was the go to back in the day. And then I know Next then came out with their own SSG kind of mechanism. And that kind of split the landscape a little bit. ~So. ~To make things even more complex. So we talked about spas, we talked about status like generators. ~Let's, ~let's move on to even more methodologies here. ~Let's, ~let's talk about hybrid rendering and incremental static,~ um,~ regeneration. And how does that address the previous or the limitations of the previous approaches? James: Yeah, ~I think ~I think the issue we had with static site generators is [00:18:00] we all looked at it like it was the answer to everything or a lot of people did. And then you just started to realize there's some limitations. So part of the limitation is, let's say we do have content that updates very often. The downside to that is if I want to make a change to a blog post, ~or I don't have a great example right now of like, other things that do change very often.~ ~But let's stick with blog posts. If I have blog posts, and I want to make a change, ~I have to make a change and then run an entire build for the entire site to get that change propagated out there. There's also the idea of build time. So we haven't really had a huge concern about this in the past, I think until this point,~ there's like, ~obviously, it was top of mind for framework creators and stuff. But this became an issue for just builders who are building blogs, and especially bigger companies, as you get to ~like, ~100 1000 whatever pages, you're building all those statically, or at build time using a static site generator, you're getting into these bigger and bigger build times. And that could be I don't know, like minutes to 30 minutes, maybe an hour or something. ~And that's,~ that's getting to the point where it's significant. And it's something to pay attention [00:19:00] to. In addition to the fact that to get new content on the screen after it's updated, has to trigger rebuild where it rebuilds the entire site. And I think we just ~kind of ~realized like, Hey, this does really good for certain use cases, but we still need the ability to choose to have a server when we want it for a content that may. update on a regular basis, or just a page that we want specifically to be server side rendered and not static. And this is where hybrid frameworks came in. And this is where I think Gatsby really fell behind is next JS to me was the first one that did hybrid in a way that really made sense and was very accessible. You had two functions, get static props and get server side props. And by using either one of those you opted into statically generated pages or server side rendered pages. And it couldn't have been ~easy ~any easier in my mind. And I think one of the things that held Gatsby back one is that they really fought the server side rendering for a long time. They do [00:20:00] it now. But they really fought that. And from my perspective, and I think they lost people who went to Next. js because of that. And they also are really tied to the GraphQL ecosystem where I had never done GraphQL before, I could get around it enough, They had good extensions in a marketplace for different plugins and stuff, but you were tied to that ecosystem versus next chance, just gave you a function and you could use GraphQL, you could use a rest request to like, whatever, get whatever you need. you could do whatever you wanted and still have the power of doing static and server side rendering whenever you need it to. And that was where, like I said, I think Gatsby really fell behind and Next. js really took over Gatsby has since kind of embrace the world of server side rendering, but it's been so long that I've touched it. Like I don't even know what that experience is like ~inside of ~inside of Gatsby these days. So the one issue that we didn't quite solve, though, is the long build time. So ~if, ~if you're using a hybrid framework and you stick with static content, you've got, if you have a bunch of pages, you've got a [00:21:00] long build time. You've also got that delay of having to run an entire bill just to get fresh updated content for an individual blog post in the hands of users. And that's where Vercel, I think coin, this is incremental static regeneration came in. And so the example is like with a static site generator, if I have 30 posts at build time, I'm going to make a request to get all 30 per posts and I'm going to build all 30 pages. When you scale it up to 100s or 1000s of pages, the reality was like, different pages got a lot more traffic than others, they were a lot more popular than others. So incremental static regeneration says ~like, ~alright, at build time, let's just choose whatever you think is the best number. But let's use a subset of your blog posts, the top 10, the top 50, the top 100. And let's build those in that same exact process of static site generation, we'll just have that out there. And then what will happen is we have a server component to this, we're able to take advantage of the hybrid [00:22:00] environment. And now when a request comes in for a page that we haven't built yet, let's just go and build that thing. And then after we build it, that thing will be cashed ~just like it ~just like the rest of the pages and then available for anybody else that comes and sees ~that ~that page later on. So this was, I think a pretty big step forward and combining truly combining the benefits of a static world with the ability to solve the long build time and that delay to having fresh content on your page. Now, the last thing that they added was not only the ability to kind of build that on demand if it didn't already exist or hadn't already been built, you also had the ability to do ~like ~validation, I guess with caching. And so you could say ~like, ~I want to revalidate this every 30 minutes or so. So, ~um,~ stale while revalidate says ~like, ~I'm going to get a copy of the page the first time, for example, and it's going to mark it somewhere on the server where it knows what time that was accessed. ~It will, uh, ~the next request that comes in, in 29 minutes, [00:23:00] still get the same page at 31 minutes. You're still going to get the same page, but behind the scenes, what it's going to do is kick off a rebuild revalidation of that page to make sure it has the latest content. And then the next person that comes, if there's been an update in the database, for example, they'll get that latest copy. So again, I think a ~pretty, ~pretty big step forward and truly taking advantage of the hybrid. methodology of being able to do statically generated pages and anything on the server that you need ~to, ~to help mitigate some of the issues that came with that. Chris: Yeah, I thought incremental static regeneration was just revolutionary. Just being able to say, okay, only a small subset of people pay the cost of not hitting the cash. But benefits, ~you know, ~infinite number of people afterwards. And I thought that was like one of the coolest things I saw when it first came out. I was like, Oh, I didn't even ~like ~think about doing it like that. ~Um, ~so kudos to them. They really are coming out with some ~really, ~really cool stuff over there. So we mentioned all these new methodologies. So ~what, ~what are like the practical implementations of using these techniques and like [00:24:00] large scale applications? James: Of using like hybrid ISR, Chris: Yeah, ~I guess like, ~I guess ~like ~pick your poison, right? James: Yeah. ~I think, ~I think the biggest thing is understanding the trade offs of when, where, and how, and the impact. And again, I go back to the initial conversation of that's why ~Okay.~ I feel like web has gotten so complicated as we have a lot of options that solve very specific use cases and problems that then to make educated decisions, you have to know what those problems are and what the solutions are. ~Um, ~so I think like big company, you look at which as on an individual page level, is this content going to change a lot if you have a bunch of static content, maybe we look into ISR and we deprioritize some of the pages based on views or most recent or like whatever that is. and take advantage of ISR. Um,~ and, ~and pay attention to the performance ~as, ~as you go through. And I don't know, like what the general consensus is ~on, ~on metrics tracking there.~ I work with, um, I don't know. I pay, I pay a lot of attention to,~ I'm starting to pay [00:25:00] a lot more attention to performance. So whatever, like your tools are that you use, I think those performance metrics are the things that then guide you on where to go next in terms of what problems to solve, because again, there's a lot of different options. fine tuning to take advantage of those options to solve your specific use cases, I think is the key. Chris: Yeah, I think being able to choose an approach is just so complicated nowadays. ~Um, ~you pretty much have to be aware of everything we've talked about,~ or,~ or you just pick one framework and just assume it can solve all your problems. ~Um, ~I believe many people are ~chasing that, ~chasing that unicorn to have one framework just do everything properly. ~Uh, ~so yeah, ~I can, I can, ~I can actually empathize. deeply with anyone new coming into the space, having to build anything at scale and understanding everything we just talked about. It's actually~ really, ~really hard. ~Um, ~so let's get into the juicy stuff. ~The new, ~the new kid on the block is server components. Can we talk about how this is different from everything we just mentioned and what are the advantages? James: Yeah. So let's say I guess the main comparison is like traditional server side rendering. So let's [00:26:00] go with server side rendering again. One more time where we have a request come into the server. Server makes a request to database. It gets all the data it needs from the database and then it responds with markup to the browser. Now we can introduce the concept of time to first byte and time to first byte says like from the time the request from the browser leaves to a server. How much time does it take to get the first bite of data back? And that like markup is probably what we're talking about. And so if you look at that workflow with traditional server side rendering, you have to do all of that database requests. You have to finish all the database requests. You have to generate all the markup before that first bite actually gets sent back or received by the browser. So server components. This is a lot of people are very I think rightfully so eager to clarify server components is a react thing, which I think is fair. I think it also gets construed, or ~like, ~conflated with Next. js, because Next. js, I think, is the first one to really take this and make it mainstream to the point where people are using it. And so server components, the idea [00:27:00] is, ~I can ~I can have a react component run on the server, where it can actually query data from a database as well. And then it can return back ~kind of ~a,~ um, ~non interactive react component. So you ~can't, ~can't do things like use state and use effect and that sort of stuff, but it can be used just as a templating language combined with logic to query data to then return back markup. Now you combine this with the idea of suspense boundaries, where ~like ~while some data is loading, I want to show a loading indicator as an idea. We get to what Next. js has provided, like baked in to a situation where you can make a request to the server, the server, if there's async, or if there's data that it needs from a database, it can kick off the request to get that data. But understand ~like ~not everything in that page is dependent upon data from the database. So if we go back to the blog example, like you can have your nav bar stays the same going back to the implications of why we, a big reason why we created spas, the [00:28:00] nav bar stays the same, the footer stays the same. ~Okay. ~The sidebar stays the same. It's basically static content. The only thing that's changing is something dynamic in there that actually needs data from a database. So what can happen is Next. js can respond back. with a static page with placeholders for this asynchronously loaded data that will come eventually. So it sends back a page to the browser. And ~it something ~I don't know, ~like specific ~specific details, but there's a header in there that says ~like, ~Hey, I'm going to continue to stream updates to this to you as I get them available. So it responds back with HTML, while it's still processing a request on the back end ~from ~from the database as an example, or data source, whatever it is. And then when that response gets back from the database, it then streams that update to the browser. And server components has like a payload definition and logic to be able to handle when this stuff gets streamed in, it knows which [00:29:00] placeholders spot inside of the existing markup that it has to replace this new content with. And so the, the thing is typically you'll send back initially. inside of suspense boundary, a loading icon of some sort that will be there first, your time to first bite is really good because you didn't have to wait for any database queries to finish before actually sending back markup. And then as the database query finishes asynchronously, you're streaming that data back react knows how to take that stream data, replace it into that spot or that slot. That it ~kind of ~set aside with that loading indicator to bring in that fresh data. This is a ~big, ~big change, I think, in, in what we had done before. And we're again, taking all the things we've done in the past and combining them in a way where we continue to solve different challenges in a really cool way. Chris: Yeah, I think the streaming factor is a really big advantage for the performance improvements. [00:30:00] Because I think before, like you said, we would have to wait for the request to finish before we could actually render any markup. I guess it still doesn't solve like, you could potentially still see a loading spinner, it just wouldn't be there as long, right? Okay. James: there, there's the trade off, ~right. ~Of ~like ~loading spinner on the front end. versus,~ um,~ time to first bite. So you're increasing time to first bite, which in theory helps increase your performance and SEO, because that sort of stuff gets factored in. And you're potentially ~handling, uh, ~putting a little bit of that burden on the user. What's interesting is Next. js 14 specifically, the majority of that stuff actually got cached after the fact. as a like statically generated page from build time. I actually didn't know this. And so Next. js was doing a lot of aggressive caching on that sort of stuff. Where an example platform I'm working on as deals for devs on the homepage, it uses a server component to query feature deals, and then it ~like ~uses server [00:31:00] components to send those back to the browser. What I didn't know is that type of configuration by default with Next. js 14 was cached. So it was actually being served statically. from a CDN after I built it and deployed it. The reason that was very confusing is one, I'm writing this code to request something from the database seemingly real time. And I hadn't experienced this issue running locally, that I experienced after I published it, where I made an update in the database, and I expected on a page refresh, it would go and grab the latest data. But because that page itself was cached originally, It wasn't getting that. So then you can ~kind of ~do like ISR with that sort of thing to have a revalidate tag or property on those pages with an amount of time for how often it should be revalidated, I think I added just to get it to be updatable. I added like a 120 seconds. So every two minutes go and revalidate this thing, which I think ~is, ~is too much to be honest. But with Next. js 15, they've ~kind of ~backtracked from that aggressive built in automatic [00:32:00] caching, but do have the hooks for you to do that caching yourself. Chris: Gotcha. ~I've, ~I've been playing with the server components quite a bit, and that was one of the big things that really surprised me. And I know there's a lot of like variables you can export from like a page that will change how it James: it. Yeah. Yep. Chris: and understand what all those little levers you can do to pull in, pull and push. So yeah, server components. Super awesome. I definitely recommend everyone to check those out. Can be pretty overwhelming ~if I, ~if I can admit that. ~Um, ~but let's ~kind of, ~let's ~kind of ~look forward here. I want to talk about ~like, ~what do you personally think are going to be like significant challenges of web development? James: Yeah, I think challenges from a building perspective is still the learning like understanding. It goes back to what we said earlier, understanding when and where and how code runs on the server on the client and what are the implications of all of that stuff. ~Um, ~I do want to, I'll maybe tweak my response a little bit to mention another future addition to this.[00:33:00] Which is partial pre rendering in Next. js, and then from an Astro perspective, server islands.~ So, when, even if we don't cache a server component, a page that uses server components, we're ~Okay, let me backtrack. ~There's, ~there's two different places that you make a request to. If you have a statically generated page, your request ~kind of ~goes to a CDN. CDNs replicate these files all over the world. So if I'm in Memphis, it's going to make a request to like US East one. I'm in Japan. It's going to make a request to a CDN node in Japan or like in Asia, somewhere closer by. ~If you're, ~if you're not having a statically generated page, that's on a CDN and it's making a request to a server, that server traditionally is really only living in ~one, um,~ one data center region. So in that same example, I make a request from Memphis, it goes to us East one, if you make a request from Japan, that makes a request all the way back over to us East one as well, which is a long way. And that has a noticeable impact on performance. So basically, partial pre rendering in Next. js, and then server islands and [00:34:00] Astro. Take this one step further, which allow you to have these dynamic parts. So using server components inside of next JS or like loading data. On the server in Astro, but looking at your entire page as a whole, basically ~kind of ~slotting out which one of those things is dynamic and then serving that entire page statically from a CDN with placeholders inside of there that with a minimal amount of JavaScript know how to fulfill those dynamic parts. So in theory, what you get is the benefit of server components without the need Of making requests back to one individual server in us East one by default, you get the benefit of having a static page, for lack of a better word, static can mean a lot of different things in a lot of different contexts, but a static page across the CDN and inside of it with minimal amount of JavaScript knows how to finish. those dynamic [00:35:00] parts, whatever that is an authenticated user icon, or maybe you're loading comments for a page, whatever. And that I think is ~really, ~really cool. Also going back to like, the struggles of building understanding that and the magic that they do for you. It like it's only escalating, we're solving more and more problems at a ~deeper, deeper, ~deeper level. which is ~really, ~really cool. And it's fascinating what we can do with kind of the same core fundamentals we had 20 years ago. We're just now like leveraging them to do more and more like things have changed. But ~like, ~a lot of it's just core, I'm going to do stuff on the server to see where that's come is really cool. It's really exciting. It also gets more and more daunting to understand all of the when, where and how of where your code is. Chris: So let me break that down and make sure I'm understanding what you just said. ~Um, ~I was aware that the partial pre rendering thing was, I think that came out a little bit ago or they announced it a while ago, but I never, I never tried to play with it. But if I'm understanding it right, it sounds like the static part of the site, you [00:36:00] can actually get fetched from a CDN right next door to me. ~So, ~so it's like almost as if it was a statically site generated site with no dynamic content. However, within there, there's a little portal. That will say, Hey, I'm dynamic. I have to go all the way to US East one or wherever my origin is and get that content first, like before we would actually always go to the origin or wherever the data center was. So we get the best of both worlds. Am I understanding that James: ~yeah, ~yeah, Chris: That's super cool. ~That~ James: it is. And I think that's one of, when we talk about the performance and benefits to server components and different things now, I think that is one of the topics that is overlooked. That is one of the most important. And that is when you make a request to your site,~ where, ~where is your request going? ~And ~Anytime you can get it on a CDN, which going back to statically generated pages, they're replicated across the world. It's always going to be faster across the world than if you're having to go back to a server. Even if your server is responding back with a static HTML file, it's always going to be faster replicated on a CDN across the world for all [00:37:00] users than if you only have it coming from one place. In this case, by default, it's often US East one. Chris: Interesting. Yeah, ~I'm going to, ~I'm going to need to play with that because I think I have some performance issues on my side ~of, for, ~for further away places. ~Um, so. ~Cool. We're wrapping up here, but I wanted to ask you another question about just like what upcoming technologies or trends are you most excited about and how do you think they will impact our industry? James: Both of the things that I just mentioned,~ um,~ I think are ~really, ~really cool. ~I'm a huge fan of, uh, ~I'm a huge fan of Astro and one thing we hadn't talked about in next JS world again, next JS really has a knack for taking a concept and making it really mainstream. ~And, ~and one of those things is actions. And so actions, If we think back to doing forms in react, for example, ~we have, ~we use you state for each one of the properties. We then have an on submit handler. That thing does event dot prevent default to prevent the form action. It makes a fetch request to the backend by sending data. It gets it back. It shows validation and error messages, et cetera. What a lot of people have ~kind of ~realized is ~we've, ~we've really just forgone the basics of how [00:38:00] the web works specifically with forms, like forms, built in HTML forms, have logic to send the request to the backend. with all the data from the actual form inputs without having to track those values and state. And so actions is a way that kind of in some ways helps us get away from that where you can take a traditional form with name inputs, etc. And you can define a function that runs on the server. And you can assign that as an action to the form inside of your ~like ~front end form component and what happens is next JS in that case specifically is going to And I guess ~this, ~this also has ~like ~React underpinnings. ~Like ~this comes from React that's incorporated into Next. js. but it will take that action and you just from a code perspective, say this is the function I want to call next JS is taking care of connecting the front end and the back end. And what it does is it actually uses JavaScript to do what you've already done in the past, which is write that fetch request to send stuff to the back end and then get [00:39:00] data back whatever it is. And then also works with progressive enhancement where if you have no JavaScript, it's just going to do a regular form submission, which is what the web does and has done for years. And there's other details in there that I've actually been doing a lot with forms recently of ~like ~trying the different use cases and diving a little bit deeper into individual components and hooks and things. But that's ~kind of ~the idea. I think that's really cool. I think the more it's really cool to see like the get back to the basics idea where we build some stuff into the framework that allows us to take more advantage of just what's built into HTML and forms and that sort of stuff. The thing about Astro I've talked a lot about Next. js I mentioned Astro I love the thing about Astro is everything that they do, they absolutely nail from a developer experience more so than any other product or framework that I've ever used or seen. And so Astro implemented actions, and they have where to define an action, you also define a [00:40:00] Zod schema with it. And it handles the val like you define the schema, give it to it. And in your definition of an action will automatically handle the validation of that with Zod. In the Next. js world, you define your function, and this has kind of been Next. js thing is like, we'll give you the hooks and things, and you ~kind of do, ~do the things however you want from there. ~Um, ~but what you inevitably do in each one of your actions is you take all the form data, ~you gat ~you gather all the form inputs individually, you put them into an object, you maybe, probably use Zod, and you do Zod safe parse or parse, get the validation errors, and return those back if they're ~already.~ Astro looked at that, and has just done it for like, it's just how you define an action because it's such a universal thing. Like we always, if for reference, ~like ~you always have to have server validation on form data, ~like ~client side validation is not security. That's where your back end comes into play to actually do the security validation of that data before you try to submit to a database. So Astro just having that built in is super, super cool. The other thing that Astro has done is like working with environment variables. ~I don't, ~how many people have ~like, you ~[00:41:00] created an environment variable inside of your. env. local or whatever you're working with it. And ~you get like, uh, ~you try to initialize a SDK client or whatever. And it says like this environment variable may or may not be defined. We actually require this to be a string passed into this configuration object. Well, that's why you have packages ~and ~on top of Next. js that actually give you the ability to define like a Zod for your environment variables. And it does all the validation for you. Astro just launched where they ~like ~built that into the framework, because it's something that every application needs, where you want validation to make sure that your environment variables are configured and set up appropriately. And you want to throw errors, if not, because you need those. And Astro now has shipped that just as part of the framework, just the thing that ~like ~everyone needs, and you have to go to an outside package. Other than that, so anyway, ~like I rave, ~I talk a lot about Next. js. I love Next. js. I ~specifically, ~specifically love Astro. Because all the things that they add from a developer experience perspective, they just nail. Chris: Yeah, I think it's nice to have some things baked in. [00:42:00] I think at some point, ultimately we all end up doing the same thing. So to have the boilerplate removed and ~kind of ~effectively save us from ourselves, because if we don't add that validation in Next. js, I'm actually guilty of this. I had an action and I got hacked because I didn't validate one of my server actions. And I was like, well, if I just. Use the Zod scheme or something. ~Um, ~I want to save myself from all that disaster. So it's great that they're always thinking about ~like, ~what do people do? Almost 99 percent of the time. And why should they have to do that themselves? ~Right. Um, so I'm going to pause real quick.~ ~Do we have time for another question or are we kind of like at time here? Should we wrap up now, Emily, do my thing. Okay.~ James: ~Do you~ Chris: ~I don't know if I understand this, this, this last question. I don't know. Do you have a response for this last question?~ James: ~Is that the navigate the overwhelming number of~ Chris: ~Is it they, as in just like, okay, I can, I'm trying to see how I,~ James: ~I can respond to that. My general idea for me is like, it doesn't really matter which framework you use, like just pick one and learn it but then pay attention to concepts versus the framework because all the concepts will apply to other frameworks~ Chris: ~Okay. I'll go ahead and I'll go ahead and read this one. I was like, who's they? I'm assuming it's just the listeners.~ James: ~Yeah.~ Chris: ~Okay, cool. Um, I'm just going to go ahead and just start by reading that question and then editors can, can, can do their thing. ~So ~let's, ~let's go ahead and round this off with the last question, because I think this is going to be very important for our listeners. So how can we just navigate all the overwhelming number of frameworks we just discussed and best practices,~ um,~ to focus on what truly matters? James: Yeah, I'll start with one perspective, which is ~like ~if you're debating which one to pick, just pick one and then see what happens like you almost can't go wrong. Most of the frameworks do the same stuff. ~Like ~if you look at how SvelteKit and Astro and Next. js. And next have all changed in the last couple of years, they've made very similar changes to each other at very similar [00:43:00] times as they like ~kind of ~evolve on what best practices are. So short answer is ~like if you're ~if you're looking to learn something, go learn something new. If you're looking to build skills that are hireable, go do research for what types of jobs are hiring and what frameworks they're using, and then backtrack from there and use that thing. Other than ~like heavily ~being heavily influenced by a specific learning path or specific jobs that you're applying for, ~like ~just go pick something ~and ~I created a short on this recently, the idea like, don't learn a framework, learn to build and understand what a framework does for you and understand those concepts. Because those concepts you can then apply to other frameworks and inevitably you'll have to learn another framework like learning another framework for me is infinitely easier because I've seen eight different ways to do very similar stuff in the past where I know the problems in theory that it's going to solve for me now I just need to go learn it syntax. So I think there is something to be said for like applying for jobs and moving up in your career by being a react expert, for example. But I think the more important thing is [00:44:00] understanding concepts and being able to translate that to other situations and other scenarios, especially when you're looking for four roles. So pick something that you think is fun, pick something that's influenced by the jobs that you're looking for. stick with one thing for some significant amount of time to get a real deep feel for it and get comfortable with it before you go and look at something else. Don't be like me as best you can don't jump around and try new things all the time. ~There's like, ~there's a detriment to that. It's fun, but also just focus on building those core skills and understanding of the concepts as a whole of what framework solve for you. And those will help make it easier and easier to transition to other things in the future. Chris: Awesome. Great response. Well, it was a pleasure talking to you, James. I appreciate you coming on the show and we'll see you around. James: Thanks for having me.