You Might Not Need Server Side Rendering

It’s easy to get lost in the labyrinth of choices when building a web app these days. I jumped on the “universal” bandwagon (back when it was called “isomorphic”) early and have many learned lessons since.

A universal app is one that can execute the same code universally — on the server and client. React provides ways to render components to static markup as documented in the official docs, typically used on a Node server. This support revolutionized the way many of us think of and write JavaScript. The practicality of scaling and maintaining such a mechanism however is questionable.

Universal… Why?

Beyond the ability to share code across the stack, why go universal? Some would say SEO (just that one word). I remember the days when this was a valid point, but luckily those days are behind us. Welcome to 2015!

Times have changed. Today, as long as you’re not blocking Googlebot from crawling your JavaScript or CSS files, we are generally able to render and understand your web pages like modern browsers.

Relevance of “Serverless”

Serverless is a cloud computing execution model where the cloud provider dynamically manages the allocation and provisioning of servers. A serverless application runs in stateless compute containers that are event-triggered, ephemeral (may last for one invocation), and fully managed by the cloud provider.

What is Serverless Architecture? What are its Pros and Cons?

Ultimately, achieving an architecture of containers with clear cut concerns could be easier to manage as an application grows. An intermingling of “back end” and “front end” code in a single container would complicate building, testing and deploying. A React web app rendering client side only would align nicely in a serverless world.

Performance

Understanding serverless architecture is a good segue into considering the performance cost of a universal app. Tools like Google’s Lighthouse have become an industry standard in measuring and analyzing performance of web pages. “Time to First Byte” is impacted directly by server side rendering and is the metric with a measurement that is actually a part of several other metrics. A performance comparison of a page rendered server side, potentially impacted by side effects, against a static or cached HTML response rendering components client side could yield a vast gap.

Other Challenges of a Universal App Architecture

The main challenges I’ve faced is lack of support in React core and Webpack. Below are some examples.

• In using Webpack, achieving “parity” between server and client side bundles can get messy.
• Error Boundaries is not supported server side. This would have been a great feature in rendering alternate content server side when errors occur on render.
• Exciting new features like React.Lazy and Suspense are not available server side as noted in the official docs. I was disappointed to learn this. If this core feature was supported server side — it could eliminate the need for side effect libraries like Redux-Saga.
• Full documentation and examples of server side rendering in React is lacking. Create React App is a Facebook project that provides full working examples. To date there isn’t an official Create React App example for server side rendering.

Conclusion

The cost of creating and maintaining a universal React web app can be more than the value nowadays. Lack of server side support is becoming more common in new React core features. Performance cost could be significant in a growing app rendering server side. We may be better off without SSR.

You Might Not Need Server Side Rendering was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.