10 Rendering Patterns for Web Apps

Key Takeaways

learn web development they said it'll be easy they said pulling web development easy is the understatement of the Sentry not only are there millions of Frameworks but there are at least 10 different rendering strategies or architectures that you'll need to choose from when building a web app in today's video we'll look at all 10 of them along with the Frameworks that support them so you can make the right decision as the CTO of your project first of all though what is a rendering pattern well rendering is the process of turning data and code into HTML that can be seen by the end user this can be done on the server or in the browser and it can be done all at once or partially and these all have trade-offs in terms of user experience performance and developer experience the original and most basic rendering Paradigm is a static website in this rendering Paradigm you put together all of your web pages in advance then upload them as static files to a storage bucket somewhere in the cloud and point a domain name to them this works great even in today's world and there are Frameworks like Hugo 11t and Jekyll that can help you build them programmatically the drawback is that they're not great for websites where the the data changes often so it's only suitable for very basic websites that don't require a ton of interactivity or dynamic data eventually websites needed to be more Dynamic and that brought us multi-page applications where the HTML and data is put together dynamically on a server whenever a request comes in from a browser this means the appearance of the website can change whenever the underlying data changes many of the biggest web apps today still use this approach like if you go to amazon.com for example notice how every time you click on a link you get a new dynamically generated page from their servers in addition there are many popular Frameworks to build multi-page apps like Ruby on Rails Django and laravel as well as content Management Systems like WordPress this approach worked great until the iPhone came out then people started to realize that having this full page reload on every URL feels kind of clunky compared to the super smooth iPhone apps that's why approximately in 2010 we saw the rise of the single page application with Frameworks like angularjs and react a few years later in the spa Paradigm all the UI rendering happens in the browser you start with one HTML page as a shell then execute JavaScript to render the UI and fetch any required data with an additional HTTP request now even though it's just a single page it can still have multiple routes those routes don't point to a server they're just updated by JavaScript in the browser this has the huge advantage of feeling instantaneous to the end user unlike a multi-page application that might take at least a few hundred milliseconds or more to render the page but there are some big disadvantages one is that it requires a large JavaScript bundle which can make the initial page load pretty slow and two because it only renders a shell search engines even today have a hard time understanding any of the content on the dynamic routes and that's a no-go if you need good SEO or want people to share your content on social media a few years later it was time for a new type of framework something that could render HTML and data on the server or the initial page load then hydrate to client-side JavaScript afterwards we call this SSR today but the general idea is that the initial request goes to a server and renders everything dynamically then after that initial page load JavaScript takes over to give you the app like single page application experience this Best of Both Worlds approach is used by Frameworks like next JS nux spell kit and so on which are often referred to as meta Frameworks this is likely the most popular rendering strategy as of today but there are still some drawbacks one drawback is that you need an actual server and servers cost money a slight variation on SSR is SSG or static site generation in this Paradigm you render all of your HTML in advance then upload it to a static host like a storage bucket but like SSR it will hydrate to JavaScript after the initial page load websites like this are often called Jam stack sites and they're typically built by the same meta Frameworks like nexjs next and swell kit you get the Simplicity and low-cost hosting of a static site with the app-like experience of a spa the only bad thing is you have to redeploy your site whenever the data changes and that's why they invented ISR or incremental static regeneration this Paradigm started in next year yes and the idea is that you deploy a static site but you rebuild individual pages on the fly on your server when the cache is invalidated normally with a static site you can just cache everything permanently on a CDN making it extremely fast with ISR the Cache can be invalidated based on certain rules like a specific amount of time and when that happens the pages will be rebuilt and this allows you to handle Dynamic data without the need for an actual server deployment like you would with SSR you get the best of both worlds between SSG and SSR but the drawback is that it's more complex to set up on your own which means you'll likely need to find a host like Purcell that supports it out of the box now another problem we haven't talked about with any framework that uses hydration is that on the initial page load the app might feel like it's frozen while the JavaScript is still executing to take over the rendering process to solve this problem we have partial hydration on a large website JavaScript may have a lot to do for things that aren't even visible to the end user like maybe you have the world's most awesome and highly interactive footer but it blows up the JavaScript call stack with partial hydration you might render the components at the top of the page first and then wait until the user Scrolls down before making that component interactive many tools today support code splitting to break your apps into smaller chunks to facilitate lazy loading patterns like this but it may be possible to render even more efficiently with the islands architecture normally when hydrating JavaScript takes over the entire page but that's not very efficient because many components are just static and non-interactive with Islands you start with static HTML then only use JavaScript to hydrate interactive components this gives you islands of interactivity Frameworks like Astro facilitate this pattern what's cool about it is that you may have a page that's not interactive at all in which case no JavaScript is ever shipped to the client even though you built the UI with a JavaScript framework like react now yet another way to address inefficient hydration is a paradigm called streaming SSR which is supported in Frameworks like next js13 with the app directory thanks to building blocks like react server components basically it allows you to render server-side content can currently in multiple chunks instead of all at once ultimately this means the UI becomes interactive faster and feels more performant to the end user but what if there is a way we could get rid of hydration altogether because it seems like the source of a lot of problems well that's where resumability comes in which is a new rendering Paradigm being pioneered by the quick framework it takes an interesting approach where a website and all of its data even things like JavaScript event listeners are serialized into HTML then the actual JavaScript code is broken into tons of tiny chunks that means the initial page load is always static HTML no hydration is needed any JavaScript required for interactivity is lazy loaded in the background and with that we've looked at 10 different rendering patterns on the web I'm sure many more will be invented in the years to come but hopefully now you can go and build the website of your dreams if you want to see these patterns in action become a pro member at fireship i o to get access to my full courses thanks for watching and I will see you in the next one