What’s New in Vue.js 2.0 — Server-Side Rendering

Anthony Gore
Vue.js Developers
Published in
3 min readOct 3, 2016

Vue.js version 2.0 was officially released last week. One of the major new features in this version is server-side rendering.

At first glance, server-side rendering seems to be a magical way to make your app load a lot faster. You put the URL into the browser and…bam! There’s your app loaded with almost no delay.

Actually, your app still loads at roughly the same speed, maybe slightly slower. But with SSR (let’s use that as an abbreviation), the page arrives in the browser pre-rendered in it’s initial state. You don’t have to wait for Vue to be loaded and to make it’s modifications to the DOM before you can see something.

But, like anything, there are pros and cons to SSR. In this article we’ll look at how it works and consider if you actually need it.

How does server-side rendering work?

We first need to understand what happens when a website loads. Here is simplified breakdown of the sequential events of a Vue.js powered webpage loading:

  1. User enters the URL of a site they want to view e.g. http://localhost:3000/vue-app
  2. Server receives request from browser, sends back an HTML document
  3. Browser receives, parses and renders HTML document. But at this point the page may look “incorrect” because there are images, CSS and JS files linked in the page that have not yet been downloaded and run. So the browser now requests these files from the server as well.
  4. Let’s say one of those linked files was a Javascript file called vue-app.js. Once the browser receives this file from the server it will run it. The script initialises a Vue.js app.
  5. Now that Vue is initialised, it figures out what state the page should be in and modifies the DOM accordingly. The user now sees the page “correctly”.

Here’s the point: there’s a (usually small) delay between rendering the initial HTML page and the Vue app re-rendering the page in it’s initial state.

SSR helps minimise this delay by providing an HTML page with the app already rendered.

Server

So what’s happening server-side to allow this? Even if you have a Javascript server like Node.js, how can a server actually render a page when there’s no DOM?

As discussed in our previous story, Vue.js 2.0 also includes a virtual DOM feature. So when the server receives a request for the page, it uses the virtual DOM to figure out how to generate the HTML output appropriately.

You can wait for the server to generate the file and send it back in one go, or better yet, Vue’s SSR allow you to stream the response as it’s generated rather than all at once at the end.

Pros and cons of server-side rendering

Pros

  1. It delivers your rendered app to the user faster
  2. It can be beneficial for SEO. Site crawlers may not get parts of your page that are fetched asynchronously.
  3. Users with old browsers or no AJAX can still see something

Cons

  1. It’s not as easy to code your app. You have to think about architecting your page in such a way that both a browser and a server could render it. It can be fairly tricky and you will likely need to utilise vue-loader to modularise your app and vuex to handle state.
  2. The server may be slightly slower to respond as it has to do the work to render the page. You can utilising caching and streaming to minimise any delay.

Okay, let’s see it in action

Code snippets won’t do this justice so checkout this video I did demonstrating a basic SSR implementation using Node.js

--

--