Page Rendering: Client Side vs. Server Side
There's an ongoing debate as to whether web pages should be rendered on the client or the server. Advocates of the client side will tell you it reduces server payloads, minimizes requests, and improves user experience. Others disagree, pointing out the issues surrounding SEO and initial page load times seen through a heavy reliance on the client. While both parties bring truth to the table, there exist caveats with both strategies. Be sure to ask yourself the following questions before you decide how you render pages for your web app.
What level of user interaction will you have?
Some web apps, such as content publishing sites, are more geared towards presenting information to the user. While they may have millions of visitors every day, these users are primarily consuming content (reading blogs or other publications).
For these reasons, generating your HTML server side may be a better option. This is largely due to the SEO concerns with client side rendering, as search engine web crawlers still struggle to fully read dynamically generated content. Additionally, content publishers would naturally emphasize strong SEO to attract subscribers. If you are emphasizing strong SEO and content publishing, then use a server side template engine to render your HTML pages.
This is a great option for publishers, however many web apps rely more heavily on user interaction (clicking photos, liking posts, generating content). For these apps, a strong argument can be made for client side rendering, where requests made to the server are significantly reduced. A great example is any single page web app. The idea is that an initial payload is received from the server and used for any user interaction. This is much faster and makes for a seamless user experience, as users don't have to wait for an http request for every button they click, etc. All of the back end data they need is already there, on a 'single page'. While the user may navigate to different links within the site, JavaScript libraries (such as Angular, React, Ember) provide all the routing and template rendering via the browser. Any additional data can be retrieved asynchronously (AJAX) through JSON responses. This greatly alleviates the work load put on the server.How important are initial load times?
Page load time is critical for retaining users and keeping bounce rates low. Research has shown that page abandonment jumps exponentially just after a few seconds. It is critical that your app loads fast for any new visitors or potential subscribers.
When it comes to fast page loads, server side rendering wins. While client side rendering can reduce the number of requests you're making to the back end, you are relying heavily on the browser to pull in that initial payload and generate all the assets/libraries needed. This issue may not be apparent at first, but as your app grows in complexity, the initial load time will take an increasing hit.
It's also important to remember the amount of faith client side rendering puts on the device itself. When you deliver your HTML server side, you get the server's hardware working for you. When you rely on a client device to render your page, you're at the mercy of the client's processing power. Sure most modern web browsers are sufficient in handling JavaScript rich clients, but mobile devices are significantly less powerful than PCs.
Conclusion
Whether or not to use client side rendering depends largely on what your app emphasizes. If you're trying to build out the next social network, it may be good to explore client rich libraries to minimize requests and provide a seamless user experience. If you're a content publisher and more concerned with users finding and consuming your content, then use server side rendering to minimize initial load times and stay crawler friendly.
