React.js is Slower Than Vanilla JS ?
Tags: react, javascript, programming, beginners
Published: 2023-12-06 14:51:21

More articles you can read: 
- [Using Golang to Build a Real-Time Notification System - A Step-by-Step Notification System Design Guide](https://dev.to/nikl/using-golang-to-build-a-real-time-notification-system-a-step-by-step-notification-system-design-guide-50l7)
- [JSON is Slower. Here Are Its 4 Faster Alternatives](https://dev.to/nikl/json-is-slower-here-are-its-4-faster-alternatives-2g30)

---
I heard that recently, and there is some truth to that. Let's see the example use-case.

---

### Example Use-Case: Handling Real-time Global Orders

Imagine you have this dynamic list on a website showing real-time orders from customers worldwide. This list can get pretty massive, with the potential for 1 to 50 new orders popping up every single minute. Now, if you were to gather all the orders from a whole day and export them as a file, it could easily be a couple of hundred mb(s) in size.

The challenge here is how to efficiently update and show this constant stream of new orders on the website's frontend.

### The Proposed Solutions without React:

1. **Imperative Approach with a Linked List:**
   - In an imperative vanilla JavaScript approach, a Linked List is considered the optimal data structure. Each new order emitted from the server can be imperatively added to the DOM, ensuring a straightforward O(1) complexity. The direct command of appending to a Linked List minimizes the computational load.

2. **React's Declarative Nature:**
   - In contrast, the React way involves using state to manage an array of orders. Upon each new order, the state is updated by setting it to a new array containing all orders to date. This leads to a re-render with O(N) complexity, where N is the number of orders. The declarative nature of React, where UI is expressed based on state, introduces overhead compared to the direct commands of imperative JavaScript.

### Analyzing the Trade-offs:

1. **React's O(N) Complexity:**
   - The React approach involves reconstructing the entire list with each state update. This process has a time complexity of O(N), making it less efficient, especially as the number of orders grows. Each re-render essentially discards the old array and constructs a new one, impacting the overall performance.

2. **Imperative JavaScript's O(1) Complexity:**
   - The imperative vanilla JavaScript approach shines in its simplicity. Each additional order is a direct append to the DOM or add operation to a Linked List, resulting in a constant O(1) complexity. This efficiency is particularly advantageous in scenarios where the frequency of updates is high.

### Declarative vs. Imperative Efficiency:

In this scenario, the imperative, direct-command approach appears more efficient than the declarative, state-driven approach of React. The imperative approach embraces the continuous addition of new orders without the need for extensive reconstruction, offering a streamlined and faster solution for real-time updates.

---


> Does it mean React is slower than vanilla JS?

---


### **So is React really slower or is it a misconception?**

The prevailing notion that React is inherently slower than vanilla JavaScript often stems from a misinterpretation of its underlying principles. It's essential to debunk this misconception and understand that React's efficiency is not a limitation but rather a reflection of how developers harness its capabilities.

**1. Declarative vs. Imperative Paradigms:**
   - React operates under a declarative paradigm, emphasizing expressing the desired UI state rather than issuing direct commands to the DOM. While this approach introduces a layer of abstraction, it doesn't inherently translate to slowness. The perceived 'slowness' may arise when comparing it to the imperative approach's seemingly direct manipulation of the DOM.

**2. Context-Dependent Efficiency:**
   - React's efficiency is context-dependent and contingent on the nature of the application and the developer's proficiency. In certain real-time scenarios, the imperative approach might appear faster, especially when dealing with a continuous stream of updates. However, this doesn't diminish React's inherent speed; it merely underscores the need for strategic implementation.

**3. Unlocking React's True Potential:**
   - React becomes a performance powerhouse when developers adopt advanced coding practices and leverage optimization tools. The use of React's virtual DOM, intelligent state management, and reconciliation algorithms allows for efficient updates without the need for an entire DOM overhaul. React's efficiency shines through when developers capitalize on these features to streamline processes and enhance overall performance.

**4. Strategic Optimization and Smart Coding:**
   - React's efficiency is not a passive attribute; it requires active engagement from developers. By adopting smart coding practices, such as keying each item uniquely, optimizing render conditions, and minimizing unnecessary updates, developers can unlock React's full potential. Strategic optimization ensures that React operates seamlessly, even in scenarios with high-frequency updates.

**5. Misunderstanding the Nature of React:**
   - The misconception that React is slower may arise from a misunderstanding of its intended use. React is designed to manage complex user interfaces and dynamic data efficiently. Comparing it directly to vanilla JavaScript, especially in scenarios where direct DOM manipulation appears faster, oversimplifies the nuanced nature of React's strengths.

**Conclusion:**
In conclusion, the efficiency of React in real-time web applications is context-dependent. While imperative vanilla JavaScript, especially with a Linked List, might exhibit a seemingly faster response in certain scenarios, React can be optimized to handle dynamic data efficiently. Developers need to strike a balance, considering the frequency of updates and the nature of the application. 

---

> #### Similar to this, I run a developer-centric community on Slack. Where we discuss these kinds of topics, implementations, integrations, some truth bombs, lunatic chats, virtual meets, and everything that will help a developer remain sane ;) Afterall, too much knowledge can be dangerous too.

> #### I'm inviting you to join our free community, take part in discussions, and share your freaking experience & expertise. You can fill out this form, and a Slack invite will ring your email in a few days. We have amazing folks from some of the great companies (Atlassian, Gong, Scaler etc), and you wouldn't wanna miss interacting with them. [Invite Form](https://forms.gle/VzA3ST8tCFrxt39U9)