Understanding Server Side Rendering

Academind by Maximilian Schwarzmüller
A free video tutorial from Academind by Maximilian Schwarzmüller
Online Education
4.7 instructor rating • 26 courses • 1,411,707 students

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 - 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 2020

  • 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 service side rendering and the last video. Now this might be a concept that's brand new to you. What does suicide rendering mean. The important thing is it does not mean dead you chance or next chance is used as a templating engine on the server. It's not a replacement for handlebars for each As for. Anything like that. That's not what it is. Instead let's think about how you chase applications typically work and with dad. I mean single page applications. If you're just dropping some UI widgets into your pages which are already rendered by some other service. Well then you don't need next. But first single page applications we typically use view which of course is a client side javascript framework. Now there we have a user using the browser and the server where our APIs search from. And typically it works like get a user sends a request by entering a u r l and to server sends back the next HDMI. Deadfall contains no HMO 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 view app which runs entirely in the browser. The view APIs then responsible for rendering the UI so that you app is adding all the time elements in the browser. It's also responsible for catching any future routes you might visit. So catching any navigation actions which are triggered by clicking links and so on. So anything of that kind is handled by View. Yes you'll never get a second page from the server as long as you stay in your application. Now this index HDMI file could be service rendered. Now it's already coming from a server but as I said doesn't contain VHDL code of the finished fall the user sees because dead content is all created through javascript fruit. Now for a 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 to Google trawl or 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 the Condren 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 dead first initial page on the server and we're only talking about this. This first page user visits for any given Eurail no matter if it's the router you are or in that €3 that first page can be pre-rendered on the server on the fly. When the user requests it and that is especially where next Chaske can help you. Next choice is by default set up to contain all the functionality you need for it. So did you create a normal abuse app but it actually gets pre-rendered dynamically or even statically as you will learn on the server so that whenever a user with your page he gets it fresh from the server pre-rendered on the server thereafter we're back in the single page application world no second page is going to get rendered future yes takes over and handles all future navigation actions all future 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 obvious and this is what service had renderings all about. It's not about adding a templating engine to your back and next G-S is not a service IDE framework or anything like that it just runs on the server to pre-rendered your view apps.