A Saga of Web Rendering Woes

Rate this content
Bookmark

This talk will look at the evolution of web rendering modes and what the Jamstack movement is all about. We will build a demo project to show how a static site generator and a Headless CMS can be combined to create dynamic and engaging stories while maintaining a static site's performance and scalability benefits.

You will learn about the advantages and limitations of each rendering mode and gain a deeper understanding of how to use Jamstack to build powerful and dynamic storytelling experiences.

Alba Silvente Fuentes
Alba Silvente Fuentes
28 min
12 May, 2023

Comments

Sign in or register to post your comment.

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.

Available in Español

1. Introduction to Rendering Methods and Strategies

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

QnA

Contact, Mock Data, and Edge Rendering

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
The Future of Performance Tooling
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
RedwoodJS: The Full-Stack React App Framework of Your Dreams
React Summit Remote Edition 2021React Summit Remote Edition 2021
43 min
RedwoodJS: The Full-Stack React App Framework of Your Dreams
Top Content
Tired of rebuilding your React-based web framework from scratch for every new project? You're in luck! RedwoodJS is a full-stack web application framework (think Rails but for JS/TS devs) based on React, Apollo GraphQL, and Prisma 2. We do the heavy integration work so you don't have to. We also beautifully integrate Jest and Storybook, and offer built-in solutions for declarative data fetching, authentication, pre-rendering, logging, a11y, and tons more. Deploy to Netlify, Vercel, or go oldschool on AWS or bare metal. In this talk you'll learn about the RedwoodJS architecture, see core features in action, and walk away with a sense of wonder and awe in your heart.
Optimizing HTML5 Games: 10 Years of Learnings
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Optimizing HTML5 Games: 10 Years of Learnings
Top Content
The open source PlayCanvas game engine is built specifically for the browser, incorporating 10 years of learnings about optimization. In this talk, you will discover the secret sauce that enables PlayCanvas to generate games with lightning fast load times and rock solid frame rates.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React at Scale with Nx
React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Top Content
Featured WorkshopFree
Isaac Mann
Isaac Mann
We're going to be using Nx and some its plugins to accelerate the development of this app.
Some of the things you'll learn:- Generating a pristine Nx workspace- Generating frontend React apps and backend APIs inside your workspace, with pre-configured proxies- Creating shared libs for re-using code- Generating new routed components with all the routes pre-configured by Nx and ready to go- How to organize code in a monorepo- Easily move libs around your folder structure- Creating Storybook stories and e2e Cypress tests for your components
Table of contents: - Lab 1 - Generate an empty workspace- Lab 2 - Generate a React app- Lab 3 - Executors- Lab 3.1 - Migrations- Lab 4 - Generate a component lib- Lab 5 - Generate a utility lib- Lab 6 - Generate a route lib- Lab 7 - Add an Express API- Lab 8 - Displaying a full game in the routed game-detail component- Lab 9 - Generate a type lib that the API and frontend can share- Lab 10 - Generate Storybook stories for the shared ui component- Lab 11 - E2E test the shared component
Building WebApps That Light Up the Internet with QwikCity
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Miško Hevery
Miško Hevery
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Performance Debugging
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Hard GraphQL Problems at Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.