I know what you’re thinking: “Not another React rant!” But hear me out. I’m not here to bash React for its performance, its ecosystem, or its popularity. I’m here to argue that React was a mistake because it fundamentally changed the way we think about web development, and not for the better.
React introduced a new paradigm for building web applications: components. Components are reusable pieces of UI that can have their own state, logic, and rendering. Components can be composed together to form complex interfaces, and React takes care of updating the DOM when the component state changes.
Sounds great, right? Well, not so fast. There are some serious drawbacks to this approach that are often overlooked or ignored by React enthusiasts.
First of all, components are not a natural fit for the web. The web is based on documents, not applications. Documents are structured by HTML elements, styled by CSS rules, and enhanced by JavaScript behaviors. HTML, CSS, and JavaScript are designed to work together in harmony, not to be abstracted away by a component library.
Components break this harmony by creating a new layer of abstraction that obscures the underlying web technologies. Components make it harder to reason about how the UI is rendered, how styles are applied, and how events are handled. Components also make it harder to leverage existing web standards and APIs, such as accessibility features, forms, animations, and transitions.
Secondly, components are not a good fit for humans. Humans are not good at managing complexity, especially when it comes to code. Components add complexity by creating more moving parts, more dependencies, and more sources of truth. Components also add complexity by creating more cognitive load, more mental models, and more context switches.
Components make it harder to understand how the code works, how the data flows, and how the state changes. Components also make it harder to debug, test, and refactor the code. Components often lead to code duplication, tight coupling, and spaghetti code.
Thirdly, components are not a good fit for teams. Teams are not good at coordinating efforts, especially when it comes to code. Components create friction by requiring more communication, more documentation, and more conventions. Components also create friction by requiring more tooling, more configuration, and more boilerplate.
Components make it harder to collaborate on the code, to share common functionality, and to enforce consistent quality. Components also make it harder to maintain, evolve, and scale the code. Components often lead to inconsistency, fragmentation, and technical debt.
So what’s the alternative? Well, I don’t have a silver bullet solution for you. But I do have some suggestions:
- Embrace the web as it is. Don’t try to reinvent the wheel with components. Use HTML elements as your building blocks. Use CSS rules as your styling system. Use JavaScript functions as your logic units.
- Embrace simplicity as a virtue. Don’t try to abstract everything with components. Use plain JavaScript objects as your data structures. Use vanilla DOM APIs as your rendering engine. Use native browser events as your interaction model.
- Embrace clarity as a goal. Don’t try to hide complexity with components. Use descriptive variable names as your documentation. Use expressive function names as your communication. Use consistent coding style as your convention.
If you follow these suggestions, you might find that you don’t need React at all. You might find that you can build web applications that are faster, lighter, and easier to work with than ever before.
You might find that React was a mistake.