Before you start reading comparisons between Angular, Ember, React, Vue, Riot, etc., consider traditional server-side rendered website.
Update: Netflix redesigned their jobs website that I’m referring to in this blog post. It’s much better now, with SSR, implemented in Next.js, but still has its issues. My guess is that they are on the way of doing a full circle ending with a traditional server rendered site.
There are a lot of resources out there trying to compare JavaScript frameworks and UI libraries that can confuse beginners and intermediate web developers when they are considering what tools to use for a new website - a ton of comparisons like “Angular.js vs React.js vs Vue.js” and similar.
We all want to use latest and most popular frameworks, but sometimes we are misled into using wrong ones. Most of those JavaScript framework comparisons are about performance and rendering speed, but the real concern for most of the websites are loading speed and perceived performance. This is very important for presentational or content based websites where the main focus is on the content. They won’t benefit from rendering thousands of DOM elements on the page, but they will lose readers if page loading is slow.
I’m sure you’ve bumped into those websites where you just wanted to read a simple article, but your browser had to download a ton of JavaScript and CSS, just to show that article.
When should you consider using server-side rendering?
Define what are you developing. Is it a website or a web app?
Is SEO important? Do you expect users with a slow internet connection? Is your website interactive, and if it is, how complex user interactions are?
I’ll try to answer those questions by analyzing Netflix Jobs website. It is a single-page application built with Ember.js v2.4.6. It’s relatively new - v2.4.6 is released in June 2016.
Is it a website or a web app?
There is no clear difference between those two. I will classify Netflix Jobs as a website, based on the requirements, because the focus is on the content, and user interactions are simple. Current single-page app implementation seems wrong. Content focused websites should draw the content user is requesting as soon as possible. Single-page apps are faster on subsequent URL changes (with exceptions), but slow on the first load, and therefore not suitable for content based sites where a user can land on a particular article and wait for the browser to load several hundreds of kilobytes just to read that article.
Is SEO important?
I guess they want a lot of candidates, so the answer is “yes”.
It’s important for this website to be crawlable by search engines and bots. They need to be able to execute JavaScript code to see any content on Netflix Jobs website. Google supports SPA websites, but it’s much better for page rankings to have fast loading complete HTML document.
There are some techniques to do prerender of your SPA, but they can introduce other problems like inconsistent content.
Also, Netflix Jobs has wrong status codes, which can cause problems with SEO.
1 | curl --head https://jobs.netflix.com/get-free-viagra |
Notice that server is responding with 200 status code. The crawler will think that this is a valid page. Google may tag Netflix Jobs site as hacked or malicious.
Read this thread for to for more information.
Do you expect users with slow internet connections?
YES! I guess you’ve already heard that “the internet is getting slower”. More people are using mobile, or slow WiFi internet on the go, or accessing from developing countries with slow devices on a slow network. I’ve seen an app that needed to get 7 MB (they optimized it to 2 MB) of JavaScript for simple user interactions. It is completely unusable on my relatively new phone (Lenovo K6) with 3g connection.
Rendering your pages on the server can save a lot of bandwidth and CPU time for your users.
Is your website interactive, and if it is, how complex user interactions are?
Complex user interactions are easier to implement using a JavaScript framework. But if there are just simple interactions, you can get better results with vanilla JS, or a tiny view library. Loading 500 KB framework for a simple form handling that filters data is a bad design.
Conclusion
Do not ditch server-side rendering too soon. It’s crucial for public websites where performance and SEO are important. You may encounter similar problems like Netflix Jobs that you can’t solve quickly and efficiently.
My opinion is that we should get more into isomorphic JavaScript - pages rendered both on client and server, but that is also a hard problem to solve. You get the best of both, but for the price of complexity. I’m currently experimenting with Marko.js and Koa.js to build an isomorphic progressive web app with support for progressive server-side rendering.