Server-Side Rendering

The Complete SSR Guide

In this section I will provide you with a standalone guide for creating server-rendered Vue applications. This will be provide a very in-depth guide for those who are already familiar with client-side Vue development, webPack and server-side Node.js development.

First things first, we will take a look at what SSR is and why we need SSR.

What is Server-Side Rendering

Vue.js as we know is a framework for building client-side applications. The default behavior of Vue components is to produce and manipulate DOM in the browser as output. However, it is equally possible to render the same components into HTML strings, then send them directly to the browser, and finally "hydrate" the static markup into an app that is fully interactive on the client.

A server-rendered Vue.js app can also be considered "universal" or "isomorphic", in the sense that majority of our app's code runs on the client and the server.

Why SSR?

When compared to a traditional SPA (Single-Page Application), the advantage SSR has primarily lies in the fact:

• That it has better SEO, this is because the search engine crawlers will directly see the fully rendered page.
• As of now, Bing and Google can index synchronous JavaScript applications just fine. Synchronous is the key word there. If our app starts with a loading spinner, and then fetches content via Ajax, the crawler will not wait for us to finish. This means if we have content fetched asynchronously on pages where SEO is important, SSR could be necessary.
• It has faster time-to-content, especially on slow devices or slow internet. Server-rendered markup does not need to wait until all JavaScript has been downloaded and has been executed to be displayed, so our user will see a fully-rendered page sooner. This will generally result in better user experience, and can be critical for any application where time-to-content is directly associated with conversion rate.
  There are also some trade-offs to consider when using SSR: however, and they include:
• It has development constraints. Browser-specific code can only be used inside some certain lifecycle hooks; some external libraries might need special treatment to be able to run in a server-rendered app.
• It has more involved build setup and deployment requirements. Unlike the fully static SPA that can be deployed on any static file server, a server-rendered app will require an environment where a Node.js server can run.
• It has more server-side load. When we render a full app in Node.js is obviously going to be more CPU-intensive than just serving static files, so if we expect high traffic, we need to be prepared for corresponding server load and we need to wisely employ caching strategies.

Nuxt.js

To properly configure all the discussed aspects of a server-rendered production-ready app can be a daunting task. Luckily for us, there is an excellent community project that aims to make all of this a lot easier: Nuxt.js. Nuxt.js is a higher-level framework which is built on top of the Vue ecosystem that provides an extremely streamlined development experience for writing universal Vue applications. Better yet, we can even use it as a static site generator (with pages authored as single-file Vue components)! I highly recommend giving it a try.

Quasar Framework SSR + PWA

The Quasar Framework will generate an SSR app (with optional PWA handoff) that leverages its best-in-class build system, developer extensibility and sensible configuration to make designing and building our idea a breeze. With more than one hundred specific "Material Design 2.0"-compliant components, we can decide which ones to execute on the server, that are available in the browser - and even manage the <meta> tags of our site. Quasar is a node.js and webpack based development environment that streamlines and supercharges rapid development of SPA, PWA, Electron, Cordova and SSR, apps - from one codebase.

Previous: State Management
Next: Reactivity in Depth