Understanding Server Side Rendering

A free video tutorial from Academind by Maximilian Schwarzmüller
Online Education
Rating: 4.6 out of 5Instructor rating
43 courses
2,330,755 students
Understanding Server Side Rendering

Lecture description

Server-side-rendering is one of the core assets Nuxt.js adds to Vue development. But what does that actually mean, what is it about?

Learn more from the full course

Nuxt.js 2 - Vue.js on Steroids

Build highly engaging Vue JS apps with Nuxt.js. Nuxt adds easy server-side-rendering and a folder-based config approach.

06:40:43 of on-demand video • Updated November 2022

Build server-side-rendered single-page-applications (SPAs)
Build normal, optimized SPAs with minimal effort
Generate a static webpage from Vuejs code
English [Auto]
OK, so we heard about server side rendering in the last video. Now, this might be a concept that's brand new to you. What does server side rendering mean? The important thing is it does not mean that each year or next year is used as a templating engine on the server. It's not a replacement for handlebars, for Ejaz, for POG, anything like that. That is not what it is. Instead, let's think about how Dutches applications typically work. And with that, I mean single page applications. If you're just dropping some UI widgets into your pages, which are already rendered by some other services, well, then you don't need Knux. But for a single page applications, we typically use Beukes, which of course is a client side JavaScript framework. Now there we have a user using the browser and the server where our app is served from, and typically it works like that. The user sends a request by entering a L and to server sends back the index HTML file. That file contains no HTML code or only very basic one, but it contains your single page application. It contains links to all the scripts that need to be loaded. It essentially then starts your review app, which runs entirely in the browser. The app is then responsible for rendering the UI, so the UEB is adding all the HTML elements in the browser. It's also responsible for catching any future routes you might visit. So kaching, any navigation actions which are triggered by clicking links and so on. So anything of that kind is handled by Beukes. You never get a second page from the server as long as you stay in your application. Now this index HTML file could be service rendered. Now it's already coming from a server, but as I said, it doesn't contain the HTML code of the finished file the user sees because that content is all created through JavaScript, through the up. Now for search engine optimization, for example, this isn't as great because especially if you need to load some asynchronous data before rendering something in the screen, especially in that case, you have a problem. The Google crawler is not going to wait for you to load your content no matter how long it takes. The Google crawler just sees the empty page and that's it. And that is not as good for search engine optimization. Also, your users will have to wait for dickon them to load in front of their face instead of on the server, which might be preferrable. So what we can do is we can render that first initial page on the server and we're only talking about this, this first page, the user visits for any given URL, no matter if it's DERARTU or another URL, that first page can be pre rendered on the server on the fly when the user requests it. And that is especially where next US can help you next year is by default set up to contain all the functionality you need for that. So did you create a normal review app? But it actually gets pre rendered dynamically or even statically, as you will learn on the server, so that whenever a user withits your page, he gets it fresh from the server pre rendered on the server thereafter, we're back in a single page application world. No second page is going to get rendered. Beukes takes over and handles all future navigation actions, all future re renderings it needs to do. It's just that first initial load which is rendered on the server and which hence improves search engine finding capabilities because the search engine crawler requests all your pages. And since it sends a new request for every page, it gets a pre rendered page for every request. Hence it sees what the user sees. This is one advantage you have. You get some this and this is what server side rendering is all about. It's not about adding a templating engine to your backend. Next year is not a service side framework or anything like that. It just runs on the server to pre render your view apps.