Hacker News Reader

Comment by JDDunn9 | Hacker News Reader

It looks like React will only really speed things up when you have over a hundred items repeating. Seems like a pretty rare use-case scenario for the additional 112KB overhead React brings with it.

View on HN

Hi, I'm Jordan a member of the React core team.

React is only 32kb(gzipped) in the production build (which also has performance optimizations that the development build does not).

We've also found that React helps make the rest of your application code much smaller, which may end up being even more important - but 32kb is certainly reasonable. We're extremely conscientious of page load speed and performance at Facebook which is why we place so much emphasis on React performance - second only to correctness and proper abstraction.

ReactJs especially helps if there are more items to display (long list, classic ng-repeat). But better rendering performance is not only on initial DOM rendering but on every update of the data. So this greatly improves usability for the user as the WebApp seems more reactive to input.

Mobile Webapps should provide feedback to the user as fast as possible on input. With long lists that has been quite problematic so far, and I have been looking for solutions to make the DOM update faster. ReactJs is a great help here.

btw, I am the author of this article.

With your native angular plnkr example, change ng-repeat to:

    ng-repeat="line in data track by $index"

Now try timing again.

http://plnkr.co/edit/PHzYFa9N4RkxcDzZMcHk?p=preview

I did try your example, and yes track by $index helps but only on updating the DOm not initial rendering. Post got updated

Interesting update. I never linked ng-repeat to the initial render lag with my app (one page, 1200 - 3000 bindings), otherwise the performance is great.

I've assumed it was a server side issue I could tune before pushing to production. Thanks, now I know where to look.

If we are talking non-mobile and it takes 4 seconds off the rendering time, then I'm not sure why it's not worth 112KB? Especially since the 4 seconds are recurring costs per page and the 112KB are spread over the whole interaction.

Where are you seeing 4 seconds? The only benchmark is 1.3 seconds for 1500 rows (very large/rare) vs .3 seconds for React. I was saying that making all users download the additional file may not be worth it if only %.01 of your pages are going to see a noticeable benefit.

Quote from the article: "Rendering time dropped from about 4200ms in native AngularJs to 120ms using ReactJs." So just above 4 seconds. And yes, if you have an app where only one in 10000 pages need that sort of performance it might not be necessary. But it's a one time (per user) cost of 32KB download to improve the performance of the "challenging" parts of your app. Which can make a big difference in the perception of users. Especially since we didn't say anything about the distribution - if the 95% percentile is still 2+ seconds, the %.01 don't really matter.

I've seen serious performance problems with Angular for even reasonably sized lists (granted, with fairly complex display logic) that React handled without making the browser hang and then scrolling lag noticeably. So I'd personally rather drop the 36KB of Angular before dropping the 32KB of React. ;) But if someone is just displaying a handful of elements with simple logic and is happy with Angular's performance, then there's no need to frankenstein React into it.

heh yeah i don't really have performance benchmarks but i went React over Angular -- I've found the style to be a little odd (passing bound handler functions through descendants to update a state param in the grandparent class? surely they can prescribe something better) but the performance is perfect & the UI I'm working on is rather complex (a few hundred nested arrays of js objects that are themselves about 8 data points, with a lot of state-dependent display rules).

I feel like maybe Angular would be more convenient to program as an app, but I still have server-side logic -- my priority with a js lib is just to have a highly interactive UI even if it's just a fairly dumb state machine. To be honest, I feel like "dumb" has helped. I put just enough into state, just enough into events without being super model-oriented. Incidentally, I hear that is why Angular's perforance is poor (executes a bunch of js on model behavior even if it only results in 1 render -- not sure if this is true or not but I saw some interesting graphics of browser profiling that showed a ton of methods firing just for 1 small model update).

Reply on news.ycombinator.com