Introduction

10 years ago, Amazon found that every 100ms of latency cost them 1% in sales. Google found an extra .5 seconds in search page generation time dropped traffic by 20%. A broker could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind the competition.

In modern day front-end, resources are served to the user from a pretty broad spectrum. This is because the demands of web pages are growing. Web pages now are more interactive with the user, and consequentially the front-end resources are larger in size, which is often a problem for the visitors accessing the page. This may not seem to be the case if the server you're trying to access is near you, and you have a powerful PC coupled with a fast broadband network connection, but these luxuries aren't entirely applicable to every single visitor on the net. Larger size = longer load times, plain and simple.

CSR

On one end, we have web apps that employ traditional CSR (Client-side rendering), which is by default what most web applications use. CSR just means that all of the Javascript processing is done by the user's browser when the user accesses the page. This usually means that the HTML files are pretty plain and small.

The biggest downfall of CSR is that when the Javascript size gets bulky, the client suffers. Minification and code splitting helps greatly, but it's still not a silver bullet. React and Angular frameworks can build some amazing web apps, but large assets size is often a consequence of that.

There is also a greater negative UX when the assets are too big. For example, pages may appear to be fully rendered, but the actual time it takes for the page to be interactive (Time-to-interactive / TTI) can be much longer.

Another downfall is that CSR and Single-page applications (SPA) can often lead to search engine optimization (SEO) issues. React and Angular are primarily frameworks for building SPA. Search engine crawlers have come a long way and are better now at parsing Javascript, but it still has some issues with pages that require Javascript to be fully loaded for the page to be functional.

SSR

The other end of the spectrum is SSR (Server-side rendering), which is where the server generates the entire HTML (along with inline Javascript/CSS added to it) on the server beforehand and returns it as a response to the user, so that the user's browser doesn't have to do as much work. There are many variations of this, and even some hybrid implementations.

The benefit of SSR is that the server has complete control of what to return to the user at the controller layer. This means that the HTML can be pretty dynamic. Another advantage is that SSR allows the HTML response to be served in a streaming fashion, which is a good thing for modern browsers. By the time the user sees rendered content, the user can also expect the content to be fully interactive, since everything has been pre-generated by the server.

SSR with React (Next.js, Gatsby)

To make things more complicated, there are implementations that aren't exactly CSR nor SSR, but somewhere in between. Couple common frameworks below are React specific, and they leverage React's rehydrate API, where hydration is the process of using client-side Javascript to add application state and interactivity to server-rendered HTML. They internally use Webpack and other cool stuff to make development easy (like hot-reloading) and apply the best optimizations for production for you.

Gatsby

• Pros:
  • Gatsby works by building your React Javascript code and turning it into static HTML files. That's basically it. You can do whatever you want with these static HTML files - you can have them returned by a server, or place them in a CDN.
  • Extensive tutorials
• Cons:
  • It is slightly opinionated when trying to access data. It highly encourages the use of GraphQL over REST, and GraphQL might be an overkill for really simple APIs.
  • There can be an inconsistency (i.e. styling) between development mode rendering and production mode rendering that can be tricky to debug

NextJS

NextJS is also another solution for your React apps, except it relies on a server that will build the HTML files at run-time.

• Pros:
  • Comes bundled with server. You don't need to worry too much about setting one up.
  • Simple tutorials
• Cons:
  • Comes bundled with server. You actually need a server to make the magic work. Also slightly opinionated towards Express.
  • Might be a little tricky if you need to use Redux and you want to integrate it properly with NextJS.

Summary

Due to the evolution of Javascript and browsers, clients need to download more stuff and process more stuff. This is why web apps now have more variety in how to handle front-end resources and processing. There is no "one tool that beats all", only "one tool that meets your needs".