More articles you can read:
- Using Golang to Build a Real-Time Notification System - A Step-by-Step Notification System Design Guide
- JSON is Slower. Here Are Its 4 Faster Alternatives
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:
-
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.
-
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:
-
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.
-
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
Top comments (19)
Highly optimised VanillaJS will always be faster than any framework. Period
That said, such code would likely be a nightmare to work with. It's a trade-off
(Many frameworks are also faster than React. It normally doesn't do all that well in benchmarks)
I used to say that too, but I have learned it isn't necessarily the case. Some frameworks add features that improve performance, so it really comes down to how much overhead they add, and is it a net loss. With most frameworks, especially those that use a virtual DOM like React, they will indeed always be slower. Others, like SolidJS, will either be very very close to vanilla JS, or in some tests will exceed it. That is because there is no render loop, because it knows exactly what changed, down to the element, and only updates those elements that have changes. Check out the performance at shorturl.at/vS346 (links to krausest.github.io/js-framework-be... with a few key frameworks selected). Solid is a tiny bit faster at load time than vanilla. In the past I've also seen it beat some of the row-related operations too. In the latest benchmarks above, it only beats vanilla JS on the "partial update" test. I don't want to sound like Solid fanboy but really, it is React done right.
What is "fast"? Server load time? First contentful paint? Time to interactive? Perceived responsiveness by the user when interacting with your app? If you want to optimize for all those metrics you are going to be building a framework... Those are not things you want to constantly reinvent for every app you build imho.
As for really dry code execution performance... React = JS, there's no difference in execution performance. A line of JS code executes exactly as fast as a line of JS code. It's not a different language in that regard like rust for example.
We really need to stop saying React is just JavaScript. That is false. Much of React's code doesn't even work outside of React components. Plus, using VDOM will always have overhead.
Highly recommend taking a look at the react source code and you will see, it is infact JavaScript đ github.com/facebook/react
That wasn't the point. Of course it's built with JS, the problem is that it's not transferable JS that you can use outside of React
Yes obviously if you import a function from some package, you wont be able to use that function if you delete the package, as is the same for all JS code.
Agree. Often things that make programming faster, also makes it slower. Especially if its some sort of layer. 4gen. Languages are slower then js, js it slower then C, C is slower then Assembly.
I'm not sure I understand. React is written in vanilla JS. Of course it's only possible to be slower or at most as fast as any other JS.
React can be much faster than raw JS in this case. If it is a never ending and expanding list, you can't show all of that on the page. Simply rendering only data that is visible in viewport will gain performance many times greater than manipulating/reflow of a bloated DOM. Yes it's more complicated to implement scrolling logic but it's lightning fast to the user, regardless of data set size.
That's something you can do in Vanilla JS too. React is developped in Vanilla JS it can at much be as fast as Vanilla JS. What React brings to the table is not performance, it's maintainability, scalibility and DX.
You just gave me the best idea đĄ. Now I know how to build my chat application.
God bless you
This sounds like the old, assembly language is faster than compiled languages debate. While that's potentially true in all cases, the amount of work you needed to do in assembly language would basically offset any of those gains. Now, hardly anyone knows how to use assembly language, so we can see where this argument is going.
That being said, I do wish frameworks like react and others were made to be more efficient and more importantly, I wish they would favor saving time in maintenance over initial crafting.
These frameworks are about the developer experience and they are still sorely lacking in that respect.
Why wouldn't you do a linked list in React anyhow? New item comes in, you modify the state of the item before and your component renders itself and then its sibling if it exists.
React is just JS, it doesn't tell you that you have to use arrays instead of lists.
React is a library that runs on top of ECMAScript (vanilla Javascript), React doesn't do anything that Javascript can't do, is important to remember that. What the article provides as arguments can all be applied to Javascript as well.
While working on a React app/site you are working on Javascript but React adds syntactic sugar so is easier to work with and at the same time it provides an opinionated way to do things.
JSX, hooks, virtual DOM, fast hydration... All of React's features can be accomplish without React.
That being said I'm not saying "don't use React!" or "React is a bad library!", might be less performant but is not just about performance. It has it's benefits, one of them being that provides a great dev experience and is much easier and faster to get a finished product and much easier to maintain.
The more interesting question is: how could React be faster than Javascript as it is written in Javascript and why in the world would someone ask a question like this with the intention to get a good answer?
Can Tailwind be faster than css?
Can Unity be faster than C++?
Can NumPy be faster than Python?
You can't compare things written in a language with the language itself. You can only compare frameworks/libraries/code but not a language with code.
If you want your frontend code to be future-proof, fast, and free from the hassle of constant upgrades or weird issues caused by third-party libraries, then just write your code in vanilla JavaScript. Don't be lazy!
Every single library or framework out there comes with a lot of strings attached, though most of their creators and fanboys won't admit it. All that "fast and easy to use, implement, etc." talk is just urban myth. Sooner or later, these tools will turn into nightmares if your product evolves long enough.
They'll tell you, "Hey, use frameworks because they're more secure than writing your own code." Yeah, sure... Any zero-day vulnerability found in the framework will affect you too.
Diversity is more secure than uniformity. Nature figured this out a long time ago, but today's so-called security experts are too blind to recognize it, pushing for uniformity instead.
If you're lazy at the beginning and don't want to write your code directly in JavaScript, you'll pay for that laziness a hundredfold in the future.
And seriously, JavaScript is already a framework. Why would you want a framework within a framework?
In most cases, the reason existing JavaScript frameworks came into existence is because their creators didn't want to inherit the garbage from earlier frameworks. But by doing so, they just created more garbage for future lazy developers to inherit...
If you want to build an F1 car, then build it from scratch (use vanilla Javascript). If you want to build an RV then go buy the parts from Home Depot (use any framework or library you want).
No one should be surprised by this. React ships hundreds of kbs, which takes time to download for a poor mobile connection. Additionally, it's quite CPU intensive, which many mobile devices are lacking in. For desktops with good wifi, it's not too much of a concern, but if you're building an app for an e-commerce company (which generally have a high percentage of mobile users), and the app needs to serve above the fold content, I wouldn't recommend react.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.