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

41–50 of 191 posts

Re: Is ReactJS really fast?

#41

Post by Zer8 »

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…

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 operations that emit tons of events. So you either listen+render() on any event (very inconsistent performance if your app has any kind of complexity), or you hand-pick the events you want to react to (event-hell). Using immutable objects along with React's PureRenderMixin means you can just render() on any change, with great performance. It makes your UI purely functional, very easy to reason about, and easy to test.

Re: Is ReactJS really fast?

#42

Post by undefinedblog »

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…

I just smelt a load of prejudice here. Leave alone the technique detail(holding a debate which is better - Angular or React and here goes your rest of the day), IDE/error checking stuff isn't a problem anymore. Maybe you should try eslint, babel-eslint, babel-sublime or anything emerge since 21 century.

Re: Is ReactJS really fast?

#43

Post by megaman821 »

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…

I don't tend to think ReactJS has many advantages, just differences.

Angular 1.x is optimized around creating pages, where as React (and Angular 2.x) are optimized around creating small components.

Angular 1.x uses two-way bindings by default and you can opt into one-way bindings. React essentially does the opposite.

I have had infinite loops pop up in Angular, just by having floating point numbers that don't "settle" down to the same value. Also, it is too easy to end up with to many watchers on a page.

Also, Angular is a much more complete solution than React but I have found react-router and the fetch api get me 80% there.

Re: Is ReactJS really fast?

#44

Post by Kiro »

Seems strange that you have to use "track by" to get a speed up when it's meant to be used for something completely different. Is this really a "fix" to slow ng-repeats? Are there any side effects?

Re: Is ReactJS really fast?

#45

Post by filearts »

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 that to make a recursive directive, Angular needs to swap back and forth between `$compile`ing newly-added markup and `$digest`ing the `$scope` that is assigned to the new markup as a part of the linking phase. It is my understanding that this issue is not manifested in React.

1: http://embed.plnkr.co/1gOJjJ/

Re: Is ReactJS really fast?

#46

Post by Cthulhu_ »

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.

Re: Is ReactJS really fast?

#47

Post by claar »

darklajid wrote: post #35
feedjoelpie wrote: post #20

Earlier quoted context omitted.

> Blog posts are somewhat meaningless, arguing specific nuances back and forth. I disagree. Your "Bloop" blog post about React with its game loop analogy totally opened my eyes. That's the first time I really "got it". Moved my org to React for all new development and haven't looked back. So thank you for your "somewhat meaningless" blog post!

Going to the GPs blog doesn't seem to list a matching blog post. Got a link for me?

http://jlongster.com/Removing-User-Interface-Complexity,-or-...

Re: Is ReactJS really fast?

#48

Post by Akkuma »

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 own experience on my machine, the dbmon example in this article for Angular is significantly outperformed by the likes of cito+t7, http://t7js.com/dbmonster/precompiled.html. Angular shows roughly 6fps topping out at 6.7 for me, while t7 is showing roughly 13fps topping out at 13.8. I don't know about anyone else, but 100% more performance isn't trivial.

Re: Is ReactJS really fast?

#49

Post by bitL »

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.

Re: Is ReactJS really fast?

#50

Post by manishsharan »

Zer8 wrote: post #41
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…

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…

Thanks. I get it now!
Post reply on HN