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

91–100 of 191 posts

Re: Is ReactJS really fast?

#91

Post by mrisse »

Cthulhu_ wrote: post #46
phillmv wrote: post #21

We need to stop this cargo cult stuff. "Speed" as determined by rendering stuff to a page is actually something we can determine. Is it not possible to simply trace the framework execution? What's the point of having silly hype pieces back and forth when we're debating trivial examples that ought to be not too difficult to measure? Finally, wrt to React: it's just a view layer. Comparing it to Ember or Angular as if…

> Finally, wrt to React: it's just a view layer. Comparing it to Ember or Angular as if it were a fully fledged, swappable alternative doesn't really make sense. This every time. If there's any bloggers among you: as soon as you start doing a 1:1 comparison between Angular and React, stop.

I (apparently incorrectly) thought they were similar enough to compare. What are the significant additional features that Ember and Angular provide?

Re: Is ReactJS really fast?

#92

Post by lhorie »

Pet peeve: Can we please stop blindly abusing `track by $index` without understanding it?

The thing with `track by $index` that nobody talks about is that, like many of the workarounds in Angular, it's a footgun in disguise. Consider this: http://plnkr.co/edit/qKm7fYZFCkXHI5pkPMYL?p=preview and focus on the first input. Notice that the focus stays on the first input, instead of sticking with the value as it jumps around, so if you start typing, you'll acccidentally modify another item as well. Oops.

If you don't use `track by` (or, if you use keys as they recommend you do if this was React/Mithril/some other vdom library), you'll see that the focus stays in the input that corresponds to the value you originally clicked on, which is the correct behavior.

While this may seem like a contrived example, the underlying problem is that it silently messes up state synchronization between your data and the DOM. This can become a nightmare because anything ranging from jquery plugins and directives to mundane things like inputs (as is shown in the plunkr) or links with onmouseup handlers or filters become potential minefields where you are eventually forced to choose between decent performance and correctness (after the hours it took you to finally understand the problem).

Re: Is ReactJS really fast?

#93

Post by joewood1972 »

TickleSteve wrote: post #77
RyanZAG wrote: 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

I think what was meant was that immutability solves cache synrhoncization issues. More accurately, state synchronization issues.

If you think about the DOM as the projected state of an application, immutable data structures allow you to very simply define a functions that perform the transformation from application state to the GUI data structures (e.g. the DOM). If the state mutates this can cause cascading state changes that make this function much harder to reason about.

Re: Is ReactJS really fast?

#94

Post by Jare »

strictfp wrote: post #79
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 b…

> If game devs redraw their stuff at 100+ FPS and haven't needed mutable state

Well I wouldn't quite say that... although there was a time when "dirty rectangles" was an important feature of a graphics engine. Generally speaking, games are based on mutation of entities: to move an existing entity, we mutate their position, not recreate them in the new position.

Re: Is ReactJS really fast?

#95

Post by strictfp »

mmarklar wrote: post #89
strictfp wrote: post #79

Earlier quoted context omitted.

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.

Sorry I should have said view state.

Re: Is ReactJS really fast?

#98

Post by axemclion »

feedjoelpie wrote: post #29
iSnow wrote: post #27

Earlier quoted context omitted.

The author however has focused specifically on the often read speed advantages. They use it themselves and he apparently likes it.

I guess the point I'm getting at is that the virtual DOM's speed is really just the answer to the question "But isn't re-rendering the whole world over and over really slow?" Which is the first thing anyone deeply familiar with web UIs would ask. It's the solution to a problem that arises when you move to this programming model. It's the programming model that's the real advantage. The virtual DOM's speed is worth me…

Virtual DOM makes rendering fast, but it has extra costs in eventing and in javascript timers. Virtual DOM is not free IMHO.

Some quantitative results - http://blog.nparashuram.com/2015/03/performance-comparison-o...

Re: Is ReactJS really fast?

#99

Post by dmak »

filearts wrote: post #45

There are some situations where Angular 1.x's digest/compile cycle leads to degenerate performance and where clean solutions are all but unavailable. Building arbitrarily recursive structures in Angular leads to degenerate performance[1]. In this example, I had to introduce artificial timeouts during rendering so that the browser's UI thread is not completely locked out for several seconds. The crux of the problem is…

Actually, I believe I am facing a similar issue. I have directives that encapsulate other directives, and compiling 1000 of them is slow, but they run pretty well after they are compiled. Any thoughts on speeding up that process?
Post reply on HN