“Rendering pages during assets building” as an optimization

Server Side Rendering(SSR) is becoming a fashion. This post is about part of the fashion.

This post is based on my previous post on page rendering at assets building. I was digging into these solution in the past weeks. It’s more like small tweaks based on our current single page app stack, that makes an obvious improvement. And the core idea is virtual DOM.

The thing virtual DOM different from template engines is that it’s simply data structures we can use. String based HTML pieces are only suitable for rendering. While virtual DOM can be diffed and even transformed for markups of other platforms. It generates HTML too. In short, virtual DOM is far more flexible than templates.

However, the flexibility of virtual DOM makes it slow in HTML rendering. If you want to render HTML with React, it’s definitely slower than pre-compiled template engine. No mention Vue 2 which suggests using `vm` module to load the code, it’s a lot of work. In some cases, caching would be helpful. Redis is able to make cached pages respond really fast. But it’s not saying SSR can always be perfect idea. There are some concerns:

  • Performance, as discussed above. Optimization takes time and efforts.
  • Data fetching and authentication, render server needs to access the database for the data, which may require another chunk of code doing those business.
  • Server rendered pages are not cacheable. They are always new pages.

So I think before SSR is a mature solution, we may try a simpler one like render static content only during assets building. For some categories of apps, SSR is never a choice, like desktop apps written in JavaScript, except for rendering HTML in a service worker. So I think render page during assets building can be a transitional solution, or even long term solution for some apps.

Render pages during building is a lot simpler, no Node.js servers, no database queries. Browsers request for a pre-rendered HTML as usual, just those HTML pages are filled with some content. The major goal is to make sure visitors see things before JavaScript finishes loading. That’s is not difficult when HTML and CSS is provided in the first file.

I made a small demo with Vue 2, trying to explore how it can be done. Here are the simple steps to do it:

  • prepare the API for render app into HTML, also a script, for example, a Gulpfile
  • load the scripts into Node.js , there are probably problems to run browser code in Node, but you may polyfill the code, or you can bundle code with Webpack with code transformations
  • prepare the paths visitors may use, render HTMLs based on them.
  • hydrate data in store into a string, dehydrate them in a browser
  • make sure the DOM generated in clients match the DOM initialized from HTML

There quite some details. I’m not able to list them all. But hopefully it may help. In case you are interested, there are some demos I prepared in different libraries:

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.