The Displaced Universal React Web App in a Serverless Future 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 , 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. documented in the official docs 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. _Serverless, the new buzzword in town has been gaining a lot of attention from the pros and the rookies in the tech…_hackernoon.com 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 have become an industry standard in measuring and analyzing performance of web pages. 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. Lighthouse “Time to First Byte” 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. is not supported server side. This would have been a great feature in rendering alternate content server side when errors occur on render. Error Boundaries Exciting new features like React.Lazy and Suspense are not available server side as noted in the . I was disappointed to learn this. If this core feature was supported server side — it could eliminate the need for side effect libraries like . official docs Redux-Saga Full documentation and examples of server side rendering in React is lacking. is a Facebook project that provides full working examples. To date there isn’t an official Create React App example for server side rendering. Create React App 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.
