A Saga of Web Rendering Woes

So, hi everyone. I'm so glad to be here and I hope that you enjoyed the talk that I will give today. My main goal of today is to tell you all the problems that we face while building websites, while rendering our web applications, that we end up having a bunch of web rendering methods to use nowadays and I will show you the history behind them. So, the main thing I want you to go home and take from this talk is an overview of the rendering methods and strategies that we use nowadays to render our javascript applications, understanding what is the jamstack architecture about and the benefits that comes with it, and learn how to build a static site with a Hello CMS in just two minutes. So, this history can start with another main character than the website. We have been building websites for a long time, almost my age, and we have been starting just hosting some static files in the cloud and after some time we start creating servers with PHP or any other backend technologies and we start combining them to have a better application with more data on it and not just a static file. But the developers of the javascript ecosystem started deciding that maybe we want to have more interactive applications that will have the end user to interact with something like a form or maybe something that is more fancier. So, that's when frameworks like vue, react, or svelte or angular start creating new methods and this one was client-side rendering. So, basically, the website is now rendered in the browser, basically in the device of the end user, what we call the client, using javascript. So, when a user enters on your site it will download a skeleton html that it provides a URL to a script, a payload, that they will download and execute to render your application. So, basically, now you have a process that will render the application inside the laptop of your user. The benefits of using this method are quite obvious. It's cheaper because we don't have any server. Everything is done in the client via javascript. We have better in-application user experience because now when they navigate they already have everything from the first load and when they navigate between pages they will just see some loadings and we will retrieve some data from the APIs. So, that's how we work. And then we will have better offline support if we catch everything on the browser of the user because we don't have any api calls, imagine, you just have an application with some things, then they will have everything without the internet connection. But what happened? Of course, every rendering method that we will see will have some drawbacks. The first one was the poor first time experience. So, when you download the website the first time, if you don't have code splitting and you have everything in one big payload, it will take too much to load just one page. So, it was not optimal for a long-term usability. So, the other problem that we faced was accessibility if some people were javascript disabled from the browser because some people are doing that. It sounds weird nowadays but there is a lot of people trying to navigate without javascript. So, this was not a rendering method if our users will not have javascript enabled. But the real problem in this history was the villain, the search of gene optimization, the seo. Basically, the search crawlers when the clients are rendering up here, they didn't have the proper time to wait for the javascript to render your site. So, in the first interaction, they didn't see any content there. So, that was a problem. And of course, nowadays, they change it and now they can render our site in the search crawlers. But what happened? They will not wait forever. So, if your performance is not okay, they will not wait for your page to be rendered and that will not be indexed in the search engines. So, what was the solution to this? Our next hero, the server-side rendering. Server-side rendering start with NUX, NEXT, and all these meta-frameworks that are on top of the frameworks we use. And basically, it's rendering the html of our webpage on the server before sending it to the end user. So, now when we download a page from entering in a URL, we will download the html pre-populated in the beginning. And what this framework does is just create a universal app that will, in the background, also download the javascript with executing it that will re-rotate your page while you are navigating. So, you are getting the benefits from client-side rendering but the first load will be really performant. And what that's one of the benefits. We improved the performance in the initial load because we basically have the pre-populated html. We have better seo because now search engines don't need to wait a lot for the page to load because it's just the first page. And then we improve security because everything that we need to call to the APIs, the api tokens will be in the server. So, you don't need to have in your api, in your client, the api tokens. That's really cool. But what happens with this? Of course, if we were using server-side in the old times, we didn't have the interactivity that we have nowadays with the universal app that NUX and NEXT provide. But nowadays, it's not a problem anymore. The problem is that we have bad and slow connections. So, basically, if you are in Nigeria and your data server is in America, you will have really a bad metric for the time to first byte, the core web vital. So, basically, it will take still months to load for some people. So, that's not good. But the real villain here was the increased server load. Now, it demands more performance from the servers to generate the html because they are the ones in charge of that. And the number of server was way higher because now each time a user enters on your site for the first time, they will call the server and that means money for the business. So, if you don't have a website that has real data or maybe something that is really changing over time, maybe you don't want this solution because it's not made for your site. Imagine a publisher or a newspaper, maybe they just have a static content. That's where the new Nest Hero came. So, basically, now we have a static site generation. A static site generator generates pages during build time. So, when we develop our code and we push it to our cloud, basically, we run a process that will generate the page and that page will be cached and saved in the CDN. The CDN is a content delivery network that is close to your end user. It has multiple nodes across the world and it will be really close to the end user. And that's how you will get the page, by just calling to the CDN and retrieving that pre-populated page. And the benefits of using this rendering method is fast performance because you have, of course, a content delivery network. It's cheap because at the end you are only saving static files. It's better for seo because the first time you call to a web page, it will retrieve the pre-populated html and improve security because everything will be made in build time. So, nothing will be, there is no server to leak about or there is no api calls in the client. So, it's really secure. And it's scalable and easy to maintain because the hosting providers are just opening the bandwidth if more users are trying to access your site. But with this methodology, of course, we don't have the interactivity that we want. Nowadays, we can maybe use serverless functions or just add some code with javascript and have some client-side application inside the static site, but that's not the main goal of this rendering method. And another problem that we faced was the user authorization or data processing because if we want to have some kind of admin with a static site, this was not meant for that. But the real villain was the build time. So, basically, the real disadvantage of a static site generators is the total time it takes to build your site completely because when you build your site, you don't build the page you just created or the article you just published. You build the entire site again. Every time you change something, you will build again the complete build size. What happened that, for example, in my blog, I have just 20 articles. Okay, it will take one minute. But if you have 5,000, it will take half an hour to wait to deploy one article for your site. So, that's what this was the problem that faced that we created a new rendering method. And the next one was created by gatsby only, actually, and it's called the first site generation. So, basically, it generates only the most important pages of your site and the FAIR, all the others that are not that important for seo or for the search engines. So, basically, when a user goes to your website, it will search in the cloud and it will say, okay, I have this page catch. I will serve that one. If not, it will go to the cloud worker. It will run the process of rendering your application, send on the fly that page, and save it in the catch for later. So, the next user will have that version catch and it will be really performant. And the benefits are quite obvious. Now, we have less build time because we are only building some pages that we think that they are important. And we keep the static site generation benefits because we have seo and performance. So, that's really cool. But what happened? Only gatsby supported in the beginning. So, not everyone was using gatsby. And of course, in the vue community, no one. And we increased complexity because we need to manage to communicate with the marketing team, with the business team, which pages are important, which not, and they start deciding which one will be the first or not. But the real problem was small changes. What happened if I change a title? That I will try to run again the build process, remove all the catch pages that I created with the cloud worker, and again start the process. So, what's the main point of catching everything if at the end I will remove everything and start again? So, that's why Next decided to create incremental static regeneration. So, it's a technique using static site generation to reveal only the parts of a website that have changed instead of regenerating the entire site every time. So, basically now, we have a page that is already pre-populated from the server. And we have a version 1 catch. When the user enters, it will start a revalidation process that will generate a new page and will be saved in catch for later. But the first user will see the stale version, that is the V1, and the next user that enter after the seconds that we specify in their validate process, they will see the new data. So, now, Vercel also made this available for Next so we can use it in the vue ecosystem. And this is just mind-blowing. If you have the chance, you need to use this rendering method because it's just amazing. But basically, the benefits of using this is now we support dynamic data in a static sites. That sounds really weird because you will say, well, I will use the server. But if you have this kind of content, it's better to use incremental static regeneration. And we have availability because each time a user enters, we'll see always the V1. Of course, we'll not see the first time that the first data that you have in your database, but we'll see the full web page that you created in the beginning. And you will have faster build times because only the pages that are important will be built in the beginning and the others will be generated in the servers, something similar to the first site generation. But the problem here was that it has limited support in the beginning. Only Next was providing it. Of course, now Next, so it's okay. But what happened? What happened with this method is that it's inconsistent for real-time updates, at least in the beginning. So basically, the first visitor to a page triggered that revalidation method that I explained to you. But first, it's a full web page. So basically, the V1. And another user was seeing the V2 of that page. So they were seeing different things. And if you have an e-commerce platform and you have a cart, maybe a guy was trying to buy something that was not available anymore. So that was a problem. And for that, they resolved it creating the on-demand ISR, the 2.0 of incremental static regeneration. Because now you can call to the revalidation process from your actual api or Hello CMS. So imagine that you are editing a page and you just publish it. You can run the revalidation process only for the page that you want to change instead of waiting for the user to enter your site and start that process. That's what actually a solution. But in the meantime, all the developers were creating a new one. And this next one was edge rendering. It's a technique where the web content is cached and served directly from the edge server. It's similar to what we know as CDN. But this time, the nodes are servers. And they can run something and have computed power. So basically, now we can alter the render html that we already built at the edge before delivering to the end user. And the benefits are amazing. It works better with dynamic content. You can have now real-time data, reduce network latency because you will have always a server close to your end user, improve scalability because you have a network so you can start changing between servers if there is not available, and then you have real-time caching. So basically, you are seeing like a static site, but in the end, it's a server in the bottom. But the problem here is, well, what happens if we have a project or a website that has so many different sections that we want to build with the same framework? Well, for that, we have the iRendering. Basically, in the beginning, we were using this for combining server side and client side with the universal app. But now we have the iRendering 2.0, what in NUX is called per-routes caching strategy. But basically, now routes can be a static page generating on demand, an ISR, or just single page app, or client side application, or server side rendering. We can choose per each route of our page, a slash admin, if we want to be client side rendering, a slash blog to be a static site, and we can decide which part of our website will be rendered how. And the way of doing it in NUX is using these properties. Basically, you just define the route that you want to have as a static site or incremental static regeneration. So, in the top, you can see the incremental static regeneration version that is SWR to true. And if you want to have only a full static site, you can put the static to true, and ssr to fast will be client side rendering. And by default, it will be server side because in the beginning, NUX was server side, but then we end up having everything at once. And what happened now? Well, there is a lot of rendering methods that I can cover in this talk, but in future episodes, we will see what is Island architecture, that basically you can build a static site with some components that will be client side applications inside of your own application, progressive enhancement, start removing javascript when you don't need it. There is a lot of things that we need to learn, but of course, at the end, you will think, well, I want to deploy my site. I need to choose something, isn't it? Otherwise, I will keep learning, but never deploying a site. And that's why you choose a static site generation. And when I was building my website, I thought, okay, I want to create my front end with NUX. I have it clear. But for the back end, I don't know what I want to do. Actually, I don't know if I want to create a back end. And that's why I meant jamstack. jamstack is basically an architecture that it couples the web experience layer, what we can call the front end, from the data and business logic, what we can call the back end. So basically, now, everything is the couple and we have scalability because, of course, we are just creating a static site that will be hosted in some cloud and the cloud will be making the bandwidth available for all the users. We have flexibility. We can choose the technology that we want in the front end and in the back end. And that's my main goal. And performance because we will have a static site at the end. And maintainability because, of course, everything is easier to maintain. But the idea is that this word came from JAM. And JAM is the J is javascript, the static site generator that you will use to build your site. The A is api. So basically, where are you saving the data? In this case, I have the CMS because I work there. And then we have the markup that is basically when you build the process of generating your pages, the final html with the populated data that you are saving in the hosting provider. In this case, Nellify with the new logo that I don't understand. But yeah, Nellify is that one now. And now, what I want to show you is in a really quick way, just two minutes, how to build a static site using a Hello CMS and the jamstack architecture. So, let me show you now. Basically, this is a storyboard where I create my own repository to save the content of my website. I create a new space. So, I will just say view London. And once I can find, wait, because yeah. So, if I create the page, I will select my plan for free, I think. I don't know what happened with this when I'm sharing this screen. But okay. So, now we can go to getting started. And it has a command that will make all the boilerplate of the project for us. So, basically, I can copy it, ignore the api token. You are not seeing it. Okay. And then we will select next stream and select npm, for example. But you can choose whatever you like. And Europe because we are in Europe. Okay. So, I will say view London for calling my repo. And I will say that I want to be served in the cloud, not locally. And once it's ready, what we will do is just install the packages and run the project. Okay. So, now I need to go to view London and install the packages. And once I have them installed, to connect with the ShareBlock, I need SSL. I will create a max cert. But this is just for SSL. Ignore it. And then we can run the SSL version of our local host. And once I have it, what I will do is I will just go to the content. And the content is where all my content is, basically. And here we can see that there is a new URL for the preview of our site. I just want to see my local host. So, I will just put here really quickly localhost 3000 and save it. So, now that I have it, if I go back, I will see a 404 error because I only have the index page in NAX. And for having the index page, I need to add this last stream path. And now I will have connected the ShareBlock with my NAX application and I can just change everything and live edit everything. And now if I publish it, I want to generate my page statically. To do that, I will just go to NAX and say, okay, generate my page in a static mode. And now I want you to serve the output. Let me go public. And if I serve it, I can see now in this BL localhost, I can see in my network tab over here that I don't have any api calls because everything is already prepopulated in the html generated after I run the command generate. So, basically, that was it. And I have this slide. If you want to contact me or give me any feedback about the talk or everything that we talk about here, you can contact me at Dan Trauss in any social media. And thank you so much. Thank you. Thank you. Thank you. That was amazing. Come on, have a seat. Make yourself comfortable. We have quite a few questions coming in already. So, let's jump into them. One of the ones from Lutz was do you recommend to mock data when you need to test a component that calls an api? Well, I used to do that a lot, I will say. Nowadays, with a straight walk, you have already the JSON file that provides you with all the properties. It's easier because you have a boilerplate of the data you will have in the component when you are creating it. Because, basically, the component that you create in the HelloCMS usually is attached to the properties that you will receive in that component. But, of course, in the beginning, when I start creating my website, for example, I create mock data to create my components and then start using the HelloCMS afterwards. So, why not? Yeah, I like mock data. It's cool. Nice, nice. I'm just going to quickly refresh mine because I've got some old questions. Let's go to the next question, which is, just give me one moment. I'm going to ask my question that I had. So, while I wait for my phone to reload. When you're building websites, I know you spoke about your sites, but let's say you're building a website that was going to be used by thousands of people, you need to really focus on performance. What rendering method would you use? What kind of things would you use to inform? I know you covered this in your talk, but I just want you to go a little bit more. Yeah, actually, nowadays, what I think is edge rendering is really kicking. Every cloud platform is really pushing this kind of way of rendering our website. And if I think in the long term, if I want to have a site right now that only have articles, it's okay to build it with a static site. But if you think in the long term, maybe you will have a section that will be an e-commerce. So, it's always better to use edge rendering or something that will have a server to run from because in the beginning, of course, you don't think about an e-commerce platform, but in the end, you will have it if everything goes well. So, yeah, edge rendering. Every site is one step away from being an e-commerce platform, my takeaway. Okay, we got another question. Will hybrid rendering be the future of web content rendering in, for example, auto selected rendering? I've never heard of auto selected rendering. Selected rendering? Auto selected. But maybe it means I remember in how to select very true. Makes sense. I think it's really cool that the frameworks can do that for us because we don't need to create a new project from scratch only to build our project in that way. We can choose per route what we want. So, yeah, hybrid rendering I think is also cool. But of course, edge rendering is not part of that. So, it's like you need to be sure that you only want the ones that the hybrid rendering is providing you, client side, server side, static, or incremental. Yeah, there's so many. Yeah, there's so many. It's really interesting because I thought I knew most of the rendering methods, but there were so many that I learned about today and seeing the future of what's coming up. Yeah, the future ones are like... There's still so much that I need to learn. Also, a big shout out from anonymous, but 11 people upvoted. We really, really like your slides. I like your slide design. Oh, thank you. What goes into your design choices when you're picking slides? Well, actually, I made them myself with Figma. So, I was sitting down seeing a series of unfortunate events, the TV show that it's based on, and I was drawing the faces of them. And then I realized, okay, maybe I can do something with this. And for that, I created the slides. That's awesome. That's awesome. Someone else asked, where did you buy the nuts jewelry? Is nuts in the fashion business? Because, I mean, it's pretty cool. But you mean this one, isn't it? Like the earrings? I think so, yes. Yeah, I made it myself because I buy a 3d printer some time ago. So, I decided to create my own earrings for technology. So, definitely... But I'm not selling it. If you want, you can come. So, after the event, after she gives the talk, definitely go upstairs, pound her for some earrings for yourself as well. Someone else asked the question, does it make sense to not use nuts when starting to work with you these days? That's a good question. Yeah, of course, you can build your own ssr using the vite plugin and things like that. But I think nuts go to your back. If something happens or if you need to upgrade, they will make it for you. So, I always prefer to use something that they are building because I think that they are more experienced than me on creating server-side applications. So, I would choose nuts. Nice. Stand on the shoulders of giants. And also, in your talk, you kind of talked about all of the different ways to inform your choice about which rendering method. But there's so much to take in. And the next question is, is there any tools that you can recommend that helps people to make those choices for the best type of rendering for each route? Maybe we need to create one. Well, what you can do is... Start a pilot. Yeah. No, but what you can do, of course, is check the performance of your site. Basically, if you have a static site, the only way to measure if it's going well is the build time. You will notice it quickly because your site is not deploying until one hour later. But if you have problems, for example, with server-side rendering, that's how you can measure it with performance tools. Because basically, you can take the bad slow connection for people that are really far away from the servers and things like that. And for that, it's rendering will fix most of the problems that we have nowadays. Nice, nice. Okay. The next one has an acronym that for some reason I don't really recognize right now. But how do you handle I18N with a static site generator? How do you mean translations? Well, yeah. Actually, this is a funny one. Because the plugin that we have nowadays in the models of the Naxaco system isn't working properly with the static sites because it's in beta. But I hope that in the end will work. But basically, if you deploy a site with I18N, you will have to have all the pages generated per language. Yeah. So, that's a lot. Incremental static regeneration will help with that. Nice, nice. You have an answer for everything. I'm loving this. Expert, expert. And the last one, are there any potential issues of not rebuilding your app completely every time you deploy? Actually, not. Because if we think about huge publicists that have a lot of articles, most of them are outdated or maybe from the past. That ones are not important anymore. Maybe for a user that wants to see a specific content, they will generate it on the fly. So, incremental static regeneration or the first site generation was created because of that. Because of course, you want to have the 1,000 articles that you created lately in the search engines, but the others are kind of outdated. So, it's okay to don't build the whole site. Awesome. And last question, just for fun. Where can people find out more information about you and watch some of your awesome hip hop dance videos? Well, the hip hop is in Instagram only. But the other things in AdDamTrauss, in Twitter, I'm more there. Awesome. All right. Let's give a massive round of applause. Thank you so much.