Live data from Hacker News

Is ReactJS really fast?

blog.500tech.com

81–90 of 191 posts

Re: Is ReactJS really fast?

#81
post #74

I have been using Backbone + moustache/handlebar templates and I am not clear on why use a virtualDOM. My application has several views and in my views, I use events to sync data model changes with the view and the view's render function maintains the DOM element . None of my views have to deal with the whole DOM. Therefore, I am really confused. So with my apologies for asking a dumb question : why maintain the whol…

VirtualDOM shines when your document tree has a dynamic structure. If you never add or remove DOM nodes and just alter text contents or CSS classes then its easy to keep references to the internal nodes that need to be updated and to write "onchange" events to keep things up to date. However, if your document is more dynamic you can't keep references to the internal nodes anymore so it gets harder to write observable…

Thank you. This is the distinction I was looking for

Re: Is ReactJS really fast?

#82
post #22

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.

> 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. While AngularJS(1.x) is a bit faster now, your comment is a bit like saying Ruby can be equally fast to Java if one does it homework. AngularJS has architectural problems that can only be reduced if one doesn't use much of angular features(scopes,watches) inside directive…

> AngularJS has architectural problems that can only be reduced if one doesn't use much of angular features(scopes,watches) inside directives(which means writing components in pure js).

That's an interesting piece of advice there. Could you go more into this?

Re: Is ReactJS really fast?

#83
Developers have a tendency to get overly excited about speed. Fast database, fast search, fast framework, etc. The truth of the matter is that speed should be evaluated within a spectrum. As long as your application latency is within a spectrum, you should be just fine

Re: Is ReactJS really fast?

#84
post #61

Earlier quoted context omitted.

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…

Not saying you're wrong, but I've never heard this argument... How do you figure that immutability helps solve the cache invalidation problem? Immutability will cause cache issues, not help solve them. The answer to the question seems to be simply that immutability allows quick comparison due to references being the same so a deep comparison is not necessary, nothing to do with cache-invalidation

What are more common arguments you heard of? I'm just curious.

Re: Is ReactJS really fast?

#85
post #39

IMO Angular1 and React are so different in their approaches that it does not even make sense to compare them. If you want to base your application on a 'kind of' functional design with sane reasoning you should know what to use. With Angular2 the discussion will be more interesting, but as far as I know Angular2 is not quite production ready.

Which is why we compare results, and not their philosophies and methodologies. It's like comparing CPUs from AMD and Intel, they have different architectures, but to understand real world performances, we compare results.

Re: Is ReactJS really fast?

#86
post #69

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.

It's the same thing as using $timeout; It runs a digest at the end after a setTimeout. I wouldn't call it a good practice, but it wouldn't bother me either if I saw it in a codebase. You are also welcome to use things like $evalAsync.

Re: Is ReactJS really fast?

#87
post #69

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.

That's a sign someone has fundamentally misunderstood Angular and is hacking around their misunderstanding.

Why do you say that? What about it makes it fundamentally misunderstanding?

Re: Is ReactJS really fast?

#88
post #64

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.

You could still continue to use the track by syntax in the nested ng-repeats, but I would be careful. O(n^2) is always worrisome.

Re: Is ReactJS really fast?

#89

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…

I just have to add that this is how pages were generated server-side before XmlHttpRequest emerged. This was deliberate. Addressable and re-loadable states were part of the original design by Tim Berners-Lee. The fact that we have had this whole circus with mutable state on the client side is just a joke to me. I hope that someone invents a sane client-side lib with sane page generation quite soon. Should certainly b…

I'm no AAA game dev but I'm pretty sure games are all about mutable state. I'd love to see some examples of what you're talking about.

Re: Is ReactJS really fast?

#90
post #57

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.

This is the ONLY way I hear about it being sold.
Post reply on HN