Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is ReactJS really fast?

blog.500tech.com

Post reply on HN
Print view View original

61–70 of 191 posts

Re: Is ReactJS really fast?

#61

Post by RyanZAG »

bitL wrote: post #49

Just a question - why is immutability considered a performance improvement when in general it leads to performance degradation? I always assumed it supports a nice conceptual framework when dealing with difficult parallel algorithms but that's about it.

Immutability helps solve one of the hard problems in computer science: cache invalidation.

Mutability can always be faster given perfect optimization, in the same way as self-modifying assembly code can always be faster. However, actually doing that optimization on a byte-by-byte level is basically impossible. Techniques such as immutability makes reasoning about how to optimize general cases much simpler.

This often ends up with the trade off of higher ram usage and lower cpu usage, but a good enough general optimization can give lower ram usage too. Bad uses of immutability done for dogmatic reasons can often give you higher ram usage, higher cpu usage, and more complex code. As always, you do need to watch out for what you're using where and why.

Re: Is ReactJS really fast?

#62

Post by andybak »

Touche wrote: post #57
feedjoelpie wrote: post #13

React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead. I wasn't truly interested in React until I read this, which does…

> DOM diffing isn't there to make React faster than everything else ever imagined. This is not how React has been sold.

I've been following the rise of React fairly closely and the speed thing has never felt oversold to me. It was more: "Faster than angular on complex pages unless you jump through lots of hoops" and that still seems fairly reasonable.

Re: Is ReactJS really fast?

#63

Post by dangoor »

Touche wrote: post #57
feedjoelpie wrote: post #13

React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead. I wasn't truly interested in React until I read this, which does…

> DOM diffing isn't there to make React faster than everything else ever imagined. This is not how React has been sold.

I've seen several React talks given by Facebook people and the pitch they make is that React makes things simpler to reason about with acceptable out of the box performance (and levers to make it faster as needed). There may be some people pitching the speed angle, but I don't think it's the Facebook people.

Re: Is ReactJS really fast?

#64

Post by hokkos »

Ok the authors of 2 talks missed the Angular DSL to speed up the rendering of a 2D table. But what about deeply nested tree structure that change ? Is there a DSL to speed up that too ? If the author want a demonstration maybe he could try that.

Re: Is ReactJS really fast?

#65

Post by wnevets »

>People have sent me links to a number of other demos. All are simply missing 'track by'.

really people? I knew most of the people spewing the angular hate didn't know what they were doing but this is kinda silly.

Re: Is ReactJS really fast?

#66

Post by untog »

mikeryan wrote: post #55
feedjoelpie wrote: post #13

React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead. I wasn't truly interested in React until I read this, which does…

There's an interesting video by Netflix where they discuss using React in their stack. To increase performance on many of Netflix's TV or Console based UI's they have their own rendering engine they're using instead of the manufacturer's browser engine. This means any of React's "speed" improvements are a moot point so instead they use it because of its simplicity for UI layouts. https://www.youtube.com/watch?v=eNC0m…

Along that line of thinking, Flipboard created React Canvas, which renders directly into a tag, bypassing a lot of the DOM:

https://github.com/Flipboard/react-canvas

Re: Is ReactJS really fast?

#67

Post by iamstef »

ckluis wrote: post #8

Ironically, he mentions ember which is in the process of adopting the virtual DOM based approach.

This isn't entirely accurate as ember essentially diffs the dynamic values, but not DOM (or vDOM). In Ember the DOM is typically produced from pre-compiled templates and values are used to hydrate those templates or choose which templates are rendered.

Obviously exceptions exist, but this is by far the most common scenario.

When ember goes to "Detect" what changed, is basically ignores the DOM, and looks at the dynamic joint values such as {{#if firstName}} or {{lastName}}. Using this information, in then decides what DOM mutations are needed to bring the DOM back into sync.

As a side note: Babel.js has some related optimizations for JSX/react uses.

This all means, for DOM creation and updates the actual DOM is used.

Now this may sound scary, as we all hear the DOM can be slow. But as it turns out, some aspects of the DOM are actually quite fast, and often faster then the alternatives.

For example:

* fragment.cloneNodes to produce new content * node.textContent to update content – nicely leaves content inert, without needing costly JS based XSS escaping.

There are obviously downsides to either approach and as such likely some hybrid is ideal.

Re: Is ReactJS really fast?

#68

Post by vruiz »

Touche wrote: post #57
feedjoelpie wrote: post #13

React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead. I wasn't truly interested in React until I read this, which does…

> DOM diffing isn't there to make React faster than everything else ever imagined. This is not how React has been sold.

I disagree. The main message I got was never "React faster than everything" it was rather "React makes complete DOM re-renders fast".

Re: Is ReactJS really fast?

#69

Post by drapper »

When I was using Angular I thought doing something like

  setTimeout(function() { $scope.$digest(); }, 0);
was an ugly hack and a sign of angular's leaky abstractionism showing up. Is this considered a good practice now (or always was)?

Edit: just to clarify, I'm asking because in OP this was given as a one of the way to fix Angular speed issues.

Re: Is ReactJS really fast?

#70

Post by whoisthemachine »

Bahamut wrote: post #34
whoisthemachine wrote: post #4

The basic premise seems to be that AngularJS can be just as performant as ReactJS if you do your homework and avoid common pitfalls of AngularJS. I would argue that the beauty of ReactJS is that it doesn't have any gotchas. It's performant without needing a deep knowledge of the framework.

React just passes the gotchas to you in architecture - if you make a mistake, it increases the likelihood of the pain down the road. It also is more complex in required build tooling. That is not to say that it is a good or bad thing - each person's/company's needs are different. I use both React and Angular - I am a lot more performant developing with Angular due to exposure to it the past 2 1/2 years, but I like bo…

Hopefully that means the gotchas will be more visible to everyone, but obviously that's dependent on the direction of the architecture.
Post reply on HN