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

71–80 of 191 posts

Re: Is ReactJS really fast?

#71

Post by bryanlarsen »

Touche wrote: post #58
Zer8 wrote: post #41

Earlier quoted context omitted.

Say you want a form with as-you-type validation. You can't have a view containing the whole form and just re-render that as someone types. If you did, you'd lose the user current focus on every render. This forces you to manipulate parts of the DOM "by hand", something React abstracts for you. I find Backbone events extremely hard to work with (error-prone, super hard to test / debug), because there are many operatio…

> You can't have a view containing the whole form and just re-render that as someone types. If you did, you'd lose the user current focus on every render. This forces you to manipulate parts of the DOM "by hand", something React abstracts for you. This is not how most modern view engines work. Somehow the React community has convinced the entire JS world that they invented the idea of "only render what has changed" w…

You've got that backwards. Every other framework "only renders what has changed". React re-renders everything.

Re: Is ReactJS really fast?

#72

Post by jsprogrammer »

drapper wrote: 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.

No.

Re: Is ReactJS really fast?

#74

Post by ufo »

manishsharan wrote: post #28

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 observables but its just as easy as the static case if you use virtualdom.

Re: Is ReactJS really fast?

#75

Post by timruffles »

drapper wrote: 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.

Re: Is ReactJS really fast?

#76

Post by Touche »

bryanlarsen wrote: post #71
Touche wrote: post #58

Earlier quoted context omitted.

> You can't have a view containing the whole form and just re-render that as someone types. If you did, you'd lose the user current focus on every render. This forces you to manipulate parts of the DOM "by hand", something React abstracts for you. This is not how most modern view engines work. Somehow the React community has convinced the entire JS world that they invented the idea of "only render what has changed" w…

You've got that backwards. Every other framework "only renders what has changed". React re-renders everything.

Reread that in the context of the parent's statement. There is a misconception that every other template library blows away parts of the dom on each update and that only React will do something like input.value=newValue, but this is not the case.

Re: Is ReactJS really fast?

#77

Post by TickleSteve »

RyanZAG wrote: post #61
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…

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

Re: Is ReactJS really fast?

#78

Post by djengineerllc »

Akkuma wrote: post #48
JDDunn9 wrote: post #36

I think many of the "advantages" of ReactJS are just hype - Immutable data, one directional data flow are easier to learn, understand, harder to break etc. - This isn't anything new, these are just concepts taken from declarative programming. You could always have used those concepts in your JS. They aren't better/worse than imperative programming. That's like saying Haskell is better than C++. - Two-way binding crea…

The most interesting thing to me is that React's virtual dom implementation, according to http://vdom-benchmark.github.io/vdom-benchmark/ , is generally the slowest of the bunch. You could pretty much move to using anything else and have a faster vdom implementation and smaller library. Additionally, many out there are so similar to writing React that I don't see how using React is a win over the alternatives. In my…

Nice, cito.js shows really nice performance.

Re: Is ReactJS really fast?

#79

Post by strictfp »

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…

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 be possible.

Oh and not even performance-critical stuff like video games deal with the big mess that is mutable state. If game devs redraw their stuff at 100+ FPS and haven't needed mutable state, how come that web devs fall right into that trap? Crazy.

Re: Is ReactJS really fast?

#80

Post by bpicolo »

JDDunn9 wrote: post #36

I think many of the "advantages" of ReactJS are just hype - Immutable data, one directional data flow are easier to learn, understand, harder to break etc. - This isn't anything new, these are just concepts taken from declarative programming. You could always have used those concepts in your JS. They aren't better/worse than imperative programming. That's like saying Haskell is better than C++. - Two-way binding crea…

Routing, http, and models aren't hard problems. Blaming React for not being an entire MVC framework is silly. It's not designed to be, and there are any number of ways to solve that problem.

Being able to use it with ANY different set of solutions for MC is especially good. I can use React for UI on top of old jQuery pages if I want to. I'm not forced to change my entire application to use it.

Decoupling is a really, really BIG benefit, not a downside.

Post reply on HN