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.
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!
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.
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.
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.
The main challenges I’ve faced is lack of support in React core and Webpack. Below are some examples.
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.