As of late it's been no secret on twitter that the developer community is starting to turn away from React. The hype has finally begun to fade and the dissenting voices have begun to gain momentum. Like most things this change is not caused by one thing alone but the combination of time and small-ish paper cuts that have finally worn the glamour of the project. With that said I want to explore one of the core phenomenon that I think is behind the aforementioned paper cuts in React, that React was built using the wrong tool for the job.
You might be a little surprised, based on the title, that out of all of this I think Javascript was the wrong tool for the job and not React itself. Looking at the history of the creation of the library and the context in which some of the traditional complaints about React are levied I think tells a compelling story of Javascript being wrong for React rather than the other way around. Given the recent shift in attitude of React I think it's interesting at the very least to acknowledge the fact that it might not be React but instead the language in which it lives that is the source of most of the issues. Ultimately it's not a matter of correcting mistakes made by the team or "building it better" but leaning into the strengths of Javascript instead of trying to put them in a glass cage.
I want to give a brief history of the original creation of React at facebook as context. This will by no means be a complete history of the library but it should provide enough context to highlight the role that Javascript's limitations play in React's issues. React was originally created by Jordan Walke at facebook back in the early 2010's and was (and still is) heavily inspired by functional programming patterns. These patterns contributed to the initial hype that drove interest in React. Specifically how much of a welcome departure things like unidirectional data flow were compared to other options that were popular at the time. This connection is still around even to today as Jordan is a part of the group that created ReasonML and ReasonReact. Both tools that take the ideas of React and WebUI creation and bring them back to the original ecosystem that birthed them, OCaml.
Examining React in the context of OCaml really serves to highlight the cracks between React and Javascript. Value immutability does a lot of heavy lifting in this respect. In languages like OCaml all values are immutable and to modify those values they need to be passed into a function that makes the modification by returning a new value. Thinking of this in the context of React and you can see how the concepts apply pretty cleanly (think how props relate to the creation of React components). This same exercise does not apply as cleanly when thinking in the context of Javascript. Javascript is a language that doesn't have immutability at all. Even CONST doesn't truly mean constant (this subject is for another blogpost entirely). This means that React and the core ideas that make it so powerful are in many cases directly fighting against the language instead of working with it's strengths.
This mismatch between what the library wants and what the language provides means that programmers have to spend a lot of time and energy making sure that they're imposing the immutability themselves with no help from the language or tooling. This is only made more challenging when using 3rd party libraries since those libraries may not have been made with the specific requirements of React in mind and make use of Javascript language features that run in direct opposition to what React wants from it's environment. May aim here is not to drag on React or Javascript at all but instead to highlight some of the core incompatibility between the values of the library and the values of the language it's written in. Many of the frustrations about React and the ecosystem that surrounds it can be tied back to this simple fact that there is a core value mismatch going on and that value mismatch manifests itself in quite painful ways.
Values compatibly in software is something that only a few are talking about and is something that I think paying more conscious attention to will better serve the industry as a whole. It's important to understand what your technical values are and how those values are compatible or incompatible with the technical environment. Making a change in process, tooling, language, etc that more closely aligns with your technical values will cause a productivity speedup that feels magical. Never pick tools blindly or because of hype. Always understand the problem they were created to solve. If it's a problem you don't have maybe that tool is not the right one for your job.
Software is not a zero sum game. Tooling is not winner take all. Use what fits best and be proud of a job well done.
You might be a little surprised, based on the title, that out of all of this I think Javascript was the wrong tool for the job and not React itself. Looking at the history of the creation of the library and the context in which some of the traditional complaints about React are levied I think tells a compelling story of Javascript being wrong for React rather than the other way around. Given the recent shift in attitude of React I think it's interesting at the very least to acknowledge the fact that it might not be React but instead the language in which it lives that is the source of most of the issues. Ultimately it's not a matter of correcting mistakes made by the team or "building it better" but leaning into the strengths of Javascript instead of trying to put them in a glass cage.
I want to give a brief history of the original creation of React at facebook as context. This will by no means be a complete history of the library but it should provide enough context to highlight the role that Javascript's limitations play in React's issues. React was originally created by Jordan Walke at facebook back in the early 2010's and was (and still is) heavily inspired by functional programming patterns. These patterns contributed to the initial hype that drove interest in React. Specifically how much of a welcome departure things like unidirectional data flow were compared to other options that were popular at the time. This connection is still around even to today as Jordan is a part of the group that created ReasonML and ReasonReact. Both tools that take the ideas of React and WebUI creation and bring them back to the original ecosystem that birthed them, OCaml.
Examining React in the context of OCaml really serves to highlight the cracks between React and Javascript. Value immutability does a lot of heavy lifting in this respect. In languages like OCaml all values are immutable and to modify those values they need to be passed into a function that makes the modification by returning a new value. Thinking of this in the context of React and you can see how the concepts apply pretty cleanly (think how props relate to the creation of React components). This same exercise does not apply as cleanly when thinking in the context of Javascript. Javascript is a language that doesn't have immutability at all. Even CONST doesn't truly mean constant (this subject is for another blogpost entirely). This means that React and the core ideas that make it so powerful are in many cases directly fighting against the language instead of working with it's strengths.
This mismatch between what the library wants and what the language provides means that programmers have to spend a lot of time and energy making sure that they're imposing the immutability themselves with no help from the language or tooling. This is only made more challenging when using 3rd party libraries since those libraries may not have been made with the specific requirements of React in mind and make use of Javascript language features that run in direct opposition to what React wants from it's environment. May aim here is not to drag on React or Javascript at all but instead to highlight some of the core incompatibility between the values of the library and the values of the language it's written in. Many of the frustrations about React and the ecosystem that surrounds it can be tied back to this simple fact that there is a core value mismatch going on and that value mismatch manifests itself in quite painful ways.
Values compatibly in software is something that only a few are talking about and is something that I think paying more conscious attention to will better serve the industry as a whole. It's important to understand what your technical values are and how those values are compatible or incompatible with the technical environment. Making a change in process, tooling, language, etc that more closely aligns with your technical values will cause a productivity speedup that feels magical. Never pick tools blindly or because of hype. Always understand the problem they were created to solve. If it's a problem you don't have maybe that tool is not the right one for your job.
Software is not a zero sum game. Tooling is not winner take all. Use what fits best and be proud of a job well done.