Reputation: 690
I'm learning ReactJS
and trying to understand what really makes it "faster" and more special than solutions provided by other frameworks and libraries.
I'm aware of following:
Virtual DOM
and how React runs a diff to take minimal # of steps to determine "change" and respond/re-render accordingly as opposed to traditional "dirty-checking" operation in other frameworks/libraries.So, the statements above sound all fine and dandy to me conceptually, however, i fail to picture the benefits when i consider real life use-cases and practices:
Considering following with jQuery
:
$("#box").removeClass('red').addClass('blue');
How is it "slower" than doing the same thing the React way? The way i understand it, jQuery will directly grab 1 element from the DOM with the matching id value of "box" and remove and add class as instructed -- all specific to this element within the DOM. (Does it implement "dirty-checking" here to find #box?)
With ReactJS, it would make the same change in its Virtual DOM first (after doing a diff to find #box with minimal # of steps) and re-render the element to the actual DOM. So if anything, it's seems to be adding an extra step of comparing against VDOM.
"Hey, something changed here (event triggered)... so let's see what we're supposed to do about it (run everything bound to the event) and do it"
Any insight, pointers and examples would be greatly appreciated!
Upvotes: 9
Views: 3302
Reputation: 398
React.js is not fast. Before React.js, Angular.js was popular. Angular is uber-slow because of the large code base that needs to be downloaded before execution. So compared to Angular.js, it is faster. But in reality, you should avoid React.js in any e-commerce, blog, or company website which needs faster load times.
Moreover, many developers don't know how to test the speed of the application. Actually, the speed means load times in web applications. In other words, the time needed for the application to be ready to work. But most of React.js will tell about virtual dom's performance gains, which means code execution speed. I wrote a TypeScript library which has similar methods to jQuery, and it has a faster execution time compared to jQuery. But in reality, no human can detect speed differences in code execution as those are happening at the nanosecond level. But web application load time happens at a millisecond level, so that is much more important.
Moreover, 99.99% of web applications may not get the benefit of execution speed improvements of React.js (if there are any), and maybe only web-based games or very complex real-time financial applications get the benefit of it. So I never saw any speed tests related to the load time of web applications built by React.js or Angular.js, rather everybody is claiming it is faster because of virtual DOM and component-based design.
React.js is very popular now, and if you are a front-end developer, you may not find a job without React.js knowledge.
If are ready to get enlightened, I wrote a short review about it here which includes speed tests done via industry standard tools GTMetrix and Google's Page Speed: https://selimkoc.com/short-speed-review-for-react-js-next-js-headless-e-commerce/
Lastly, 99% of web applications are not complex applications. If you are building something really complex like Figma or that kind of software which works on a browser, there are alternative tools for faster execution, look at WebAssembly.
You can still use React.js for projects whose first load time is not that important like SaaS, Admin Panels, and Games. If you are building a SaaS, build your website (a customer-facing website which has content about your SaaS) with something faster and better SEO support and you can still use React.js for your custom app. Use next.js only if you are hopeless :) [I mean your CTO, or CEO made a final decision to use it]
Upvotes: 0
Reputation: 86220
React isn't exceptionally fast, it's fast enough. The real value of React is the declarative api it provides which lets you write better code.
Manual DOM operations have much higher potential performance, but you end up with difficult to maintain, hard to read code. This is unacceptable in large applications which is why we turn to tools like React.
Virtual DOM diffing is expensive. Usually, not expensive enough to cause you to drop frames. The difference between 1ms and 16ms for an update is nothing. All that matters is that you stay within the frame, which is why React's performance overhead is acceptable.
Upvotes: 6
Reputation: 17334
You're probably right, in this case jQuery might be faster (I haven't tested). But consider this, why are you using jQuery - wouldn't it be even faster if you did
document.getElementById("MyID").className = document.getElementById("MyID").className.replace(/\bred\b/,'');
document.getElementById("MyID").className = document.getElementById("MyID").className + ' blue';
So really, we're not trying to compete raw speed here, otherwise you would just write in pure javascript and I know companies that do this purely to be faster on mobile.
The benefits of a framework is maintenance and speed of development. Programming in pure javascript is a lot harder to scale and maintain than jQuery and similarly programming in jQuery is a lot harder to scale and maintain than React. Although the converse is true, it's much faster to get a working app with minimal functionality with jQuery (but after you build your mvp, it becomes much harder to maintain)
In small codebases jQuery might be faster than React, but when you work with larger codebases, you'll find heaps of duplicate and redundant code in jQuery and it becomes inherently slower. React however, is different - first React, segregates everything into components so it becomes much easier to reuse, second React has a cool internal engine that prevents useless rendering from slowing down your app.
So yes you are right, jQuery can be faster than React but that's really missing the point of React. Just as pure javascript might be faster than jQuery, but that's missing the point of jQuery.
Upvotes: 12