The React chain
I’ve been thinking a lot lately about the role React plays when building a web app. Companies like GitHub and Shopify, both very successful software companies, introduced React recently in areas where it makes sense. This led me to the question: Is React and everything that comes with it (e.g., abstractions, tools, libraries) an influential piece in generating value for users?
There are great things about the React stack. You can more easily unit-test the business logic of your frontend, share and use components that atomically encapsulate structure (HTML), behavior (JS), and style (CSS). Moreover, you have access to beautiful abstractions to do theme-based styling and even leverage the Typescript compiler to validate your styling object. React turns building a web app into a LEGO game where many blocks are already provided by the community.
However, with React, projects pull in a chain of drawbacks that wouldn’t exist if we didn’t add React in the first place. The first of them is having an API. Sure, if you plan to have more clients in the future, an API is a must. But what if that’s not the future plan, or it’s far ahead? You end up optimizing for a future that might never come.
At this point, one might argue that it’s possible to solve that by doing server-side rendering (SSR). True, but the moment you hydrate the app on the client, you want the routing experience to be on the client, leading to components having to fetch data through the API. We can’t move away from it. React and, more generally SPAs, force you to have two sources of truth for your data. And I forgot to mention that SSR requires your React libraries to be compatible with it, limiting the options from the exciting pool of component libraries one has access to.
It does not make sense if your sole focus is to generate value through a web app. Throw a project with a Rails or similar framework and focus on the product and not the tools and the technology around it.