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 sites, 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 over JavaScript applications, understanding what is the Yamstack architecture about and the benefits that come 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'll start creating servers with PHP or any other back end technologies, and we'll 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 help the end user to interact something with, like a form, or maybe something that is more fancier. So that's when frameworks like Vue, React, or Asphalt, or Angular started 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 users' 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. It was not optimal for a long term usability. So the other point 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 engine optimization, the SEO. Basically the search crawlers when the clients are rendering up here, they don'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 changed 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 started with NAX, NAX, 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 prepopulated in the beginning. And what these frameworks 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 that's one of the benefits. We improve the performance in the initial load because we basically have the prepopulated HTML. We have better CEO 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 Next 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 much 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 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 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 yes, 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 point that we face was the user authorization or data processing because if we want to have some kind of admin with a static site, this wasn't 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 size. What happened? 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 a day. 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 fer 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 side generation benefits because we have SEO and performance. This is really cool.

But what happened? Only Gatsby supported in the beginning. Not everyone was using Gatsby. And, of course, in the new 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 are not. And they start deciding which one will be the first or not. But the real problem was small changes. What happens if I change a title? That I will just try to run again the build process, remove all the cache 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 populated from the server. And we have a version 1 cache. When the user enters, it will start a revalidation process that will generate a new page and will be saved in cache 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 static sites. That sounds really weird because you will say, well, I will use the But if you have this kind of content, it is better to use incremental static regeneration. And we have availability because each time a user enters, we will see always the big one. Of course, we will not see the first time, the first data that you have in your database but we will see the page that you created in the beginning. And you will have faster real 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 is 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 you but first, it's a full back 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 eCommerce 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 resolve 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 Helm's CMS. So imagine that you are editing a page and you just publish 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 catch and serve directly from the edge server. It's similar to what we know as CDM, but this time, the nodes are servers and they can run something and have computed power. So basically, now we can alter the rendered 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 no 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 none available. And then you have real time catching. 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 have them, 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 irenrendering. Basically, in the beginning, we were using this for combining server-side and client-side with the universal app. But now we have the irenrendering 2.0, what in Nuxt 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. The way of doing it in Nuxt 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 a static-to-true and SSR-to-false will be client-side rendering. By default, because in the beginning, Nuxt 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.

But 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 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 frontend with Nuxt. I have it clear. But for the backend, I don't know what I want to do. Actually, I don't know if I want to create a backend. And that's why I meant Jamstack. Jamstack is basically an architecture that the couples the Web Experience Layer, what we can call the frontend, from the data and business logic, what we can call the backend. 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 frontend and in the backend. And that's what's my main goal. And performance, because we will have a static site on the end. And maintainability, because, of course, everything the couple is easier to maintain.

But the idea is that this world came from YAM. And YAM is just the J is JavaScript, the static site generator that you would use to build your site. The A is API. So, basically, where you're saving the data. In this case, I have a CMS, because I work there. And then we have the markup that is basically, when you build the process of regenerating your pages, the final HTML with the populated data that you are saving in the hosting provider. In this case, Nullify with the new logo that I don't understand. But yeah, Nullify 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 story block where I create my own repository to save the content of my website. I create a new space, so I would just say, View London. And once I can find, wait, because yeah, better.

So, if I create the page, I would select my plan for free, I think. I don't know what happened with this when I'm sharing the 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. And then we will select NUXT stream. And select NPM, for example, but you can choose whatever you like. And Europe, because we are in Europe. And okay. So, I will say, View London, for calling my repo. And I will say that it will be served in the cloud, not locally. And once it's ready, I will say... What we will do is just install the packages. And run the project... Okay. No.

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 maxsert. But this is just for SSL. Ignore it. And then we can run the SSL version of our localhost. 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 lives, basically. And here we can see that there is a URL for the preview of our site. I just want to see my localhost. 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 Nuxt. And for having the index page, I need to add this last, this real path. And now I will have connected the storyboard with my Nuxt application and I can just change everything, and now, if I publish it, I want to generate my page statically. To do that, I will just go to Nuxt and say, okay, generate my page in a static mode, and now I want you to serve the output. And if I serve it, I can see now in HTML localhost. I can see in my network top, over here, that I don't have any API calls because everything is already pre-populated in the HTML generated after I run the command and yarn 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 dantraus 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. 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 API? Well I used to do that a lot I would say. Nowadays with Storyblock you have already the JSON file that provides you with all the properties. It's easier because you have like 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 Hello, CMS usually is attached to the properties that you will receive in that component. But of course in the beginning when I started creating my website for example, I created mock data to create my components and then started using the Hello, CMS afterwards. So why not? I like mock data. It's cool. I'm just going to quickly refresh mine because I've got some old questions. All right. Perfect. Let's go to the next question, which is... I forgot. Just give me one moment. I'm going to ask my question. 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 is 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 into it.

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 eCommerce. 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 eCommerce platform, but in the end you will have it if everything goes well, you know. So yeah, edge rendering.

So every site is one step away from being an eCommerce platform, my takeaway.

Okay, we've got another question. Will hybrid rendering be the future of web content rendering? For example, autoselected rendering. I've never heard of autoselected rendering. Selected rendering? Autoselected rendering. But maybe it means hybrid rendering like how to select very truly. Makes sense. Yeah, 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 was so many that I learned about today and seen 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 for 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 then 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 get but I'm not selling it.

After the event, after she's used the talk, definitely go upstairs, hound her for some earrings for yourself as well.

Someone else asked the question, does it make sense to not use Nuxt when starting to work with Vue these days? That's a good question. Yeah, of course, you can build your own SSR using the Vue plugin and things like that. But I think Nuxt got 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 Nuxt. Nice, stand on the shoulders of giants, my boy.

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... A startup. Yeah, no, but what you can do, of course, is check the performance of your site. Basically, if you have a static site that 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 check 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? I mean translations? Well, yeah. Actually, that's a funny one. Because the plugin that we have nowadays in the models of the Naxaco system isn't working properly with 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.

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 generation will help with that. Nice, nice. We have an answer for everything. I'm loving this. Expert, expert.

And the last one. Are there any potential issues with not rebuilding your app completely every time you deploy? Actually not because if we think about huge publishers 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 would generate it on the fly. So incremental static generation or the first generation was created because of that. Because, of course, you want to have 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.

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 Adventrals, in Twitter, I'm more there. Awesome. All right, let's give a massive round of applause.