Video Summary and Transcription
This Talk discusses the problems faced in building and rendering web applications, different rendering methods and strategies, and the benefits of the Yamstack architecture. It covers server-side rendering, static site generation, incremental static regeneration, and edge rendering. The speaker demonstrates how to build a static site using a Hello CMS and the JAMstack architecture. Other topics include connecting Storyboard with a Nuxt application, mock data, hybrid rendering, and handling I18N with a static site generator.
1. Introduction to Rendering Methods and Strategies
In this talk, I will discuss the problems we face while building and rendering web applications, the different rendering methods and strategies used, and the benefits of the Yamstack architecture. I will also demonstrate how to build a static site with a Hello CMS in just two minutes. The history of rendering methods begins with hosting static files and gradually incorporating servers and back-end technologies. Frameworks like Vue, React, Asphalt, and Angular introduced client-side rendering, where the website is rendered in the user's browser using JavaScript. This approach offers cost savings, improved user experience, and better offline support. However, it has drawbacks such as poor first-time experience, accessibility issues, and challenges with search engine optimization. Despite these challenges, search crawlers can now render JavaScript-based sites.
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.
2. Server-Side Rendering and Static Site Generation
Server-side rendering allows for prepopulated HTML to be sent to the user, improving performance, CEO, and security. However, slow connections and increased server load can be challenges. Static site generation solves these issues by generating pages during build time and caching them in a CDN.
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.
3. Rendering Methods and Build Time
This rendering method offers fast performance, cost savings, improved SEO, and enhanced security. However, it lacks interactivity and is not suitable for user authorization or data processing. The main drawback is the build time required for static site generators. Gatsby introduced the first site generation method, which generates important pages and dynamically renders others for optimal performance.
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.
4. Incremental Static Regeneration
Now we have less build time because we only build important pages. We keep the benefits of static site generation for SEO and performance. Next introduced incremental static regeneration, which reveals only the changed parts of a website. This technique allows us to support dynamic data in static sites and provides faster real times. However, it had limited support in the beginning and was inconsistent for real-time updates.
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.
5. Incremental Static Regeneration and On-Demand ISR
The first visitor triggered the revalidation method, resulting in different versions of the page being seen by different users. To address issues like unavailable products in an eCommerce platform, the on-demand ISR was created. This allows you to trigger the revalidation process for specific pages, improving efficiency. Meanwhile, developers were working on a new solution.
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.
6. Edge Rendering and its Benefits
Edge rendering is a technique where web content is served directly from edge servers. It allows for altering the rendered HTML at the edge before delivering it to the end user. This method works well with dynamic content, reduces network latency, improves scalability, and provides real-time caching.
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.
7. Irenrendering and Route Rendering
We have the irenrendering 2.0, which allows us to choose different rendering methods for each route of our website. By using properties in Nuxt, we can define whether a route should be rendered as a static page, incremental static regeneration, or client-side rendering. This flexibility gives us control over how different sections of our website are rendered.
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.
8. Introduction to Jamstack Architecture
There are various rendering methods to cover, including the island architecture. You can build a static site with client-side applications, progressive enhancement, and choose a static site generation for deployment. The Jamstack architecture couples the frontend and backend, providing scalability, flexibility, performance, and maintainability. YAM, which stands for JavaScript, API, and Markup, is the foundation of this world. Now, I will demonstrate how to build a static site using a Hello CMS and the JAMstack architecture.
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.
9. Creating a Repository and Previewing the Site
Basically, I create my own repository to save the content of my website. I select my plan, copy the command, select NUXT stream, NPM, and Europe. I call my repo View London and it will be served in the cloud. I install the packages, create SSL, run the SSL version of localhost, go to the content, and preview my site on localhost.
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.
10. Connecting Storyboard with Nuxt Application
Now that I have connected the storyboard with my Nuxt application, I can generate my page statically. By running the command 'yarn generate', the HTML is pre-populated with the necessary data, eliminating the need for API calls. This ensures a fast and efficient rendering process.
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.
Contact, Mock Data, and Edge Rendering
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. 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. When you're building websites, 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? 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 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.
Hybrid Rendering and Slide Design
Every site is one step away from being an eCommerce platform. Hybrid rendering allows us to choose rendering methods per route. There are many rendering methods to explore, and the future holds even more possibilities. The slides were created using Figma and inspired by a TV show. The speaker also received compliments on their design choices and was asked about their NUTS jewelry.
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.
Earrings, Nuxt, Rendering Tools, and I18N
I made my own technology earrings using a 3D printer. While you can't buy them, you can ask for them after the event. When starting with Vue, it makes sense to use Nuxt for its expertise in server-side applications. To choose the best rendering method, check your site's performance and consider the target audience's connection speed. Handling I18N with a static site generator can be challenging due to beta plugins, requiring separate pages for each language.
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.
I18N Deployment and Rebuilding App
If you deploy a site with I18N, you will have to generate all pages per language. Incremental static generation helps with this. There are no potential issues with not rebuilding your app completely every time you deploy, especially for publishers with outdated articles. Users can generate specific content on the fly. You can find more information and watch hip-hop dance videos on Instagram and Adventrals.
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.
Comments