Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Part of implementing an efficient React app is making sure that prop/state transitions are minimized. Coincidentally, this is also (abstractly) true about any UI technology, not just React. But React sacrifices a little bit of speed in order to make the UI declarative, as opposed to the finicky, error-prone and messy way we used to do it before with frameworks like Backbone.

Have you actually developed a large React app? Because you might be surprised at how fast React really is in practice.



Large React apps are actually no faster than large apps written in Ember or Angular, and I've personally been surprised by how slow React got on a large app. At some point, in every framework, you will run into bottlenecks and none of them provide silver bullets.


> Large React apps are actually no faster than large apps written in Ember or Angular

This is (more or less) true now. It wasn't when React first showed up. Angular is also only just as fast when you actively code your apps in the same way as React (basically using a prop/state system but in an Angular way). This isn't also the method generally championed in Angular (1.x anyhow).

Ember was always pretty fast but post-React it changed a lot of how it did it's rendering... influenced by React!

So claiming that React apps are no faster is a bit disingenuous as the reason for that is because the other frameworks saw what React was doing and agreed with it.


Actually, simply using "track by" in Angular puts it on par with React's performance regardless of whether or not you follow React's patterns. You do understand that Angular 1.x's $scope is essentially a virtual DOM inasmuch as it's a javascript representation of the DOM which provides a more efficient means of diffing (dirty checking in Angular's case). "Virtual DOM" is just a fancy buzzword for React's solution to figuring out what to change. React's requirement that the entire DOM tree be re-rendered any time any state changes meant that dirty checking would be prohibitively expensive, so they had to come up with a clever workaround which, to their credit, ended up being just as performant as Angular's dirty checking.

You can use Angular 1.x in exactly the same way you use React by only ever using 1-way binding and constructing your entire application out of directives scoped to elements. The only thing Angular 1.x doesn't let you do is use JSX, but then again, you could just use plain old javascript and imperatively build up your DOM elements (which is what JSX does under the hood anyways) if you really don't want to have .html files.


Sure, but the fact that React is as fast as those other frameworks, with none of the code overhead of having to manually patch the DOM, is a benefit. React doesn't need to be faster, it just needs to be comparably fast.


What do you mean by "none of the code overhead of having to manually patch the DOM"? None of the other frameworks make you manually patch the DOM, they all do it automatically in their own way.


I actually don't know Angular or Ember well — before React I was largely using Backbone, where DOM patching is manual unless you use templates, so that's really what I was referring to. The benefits apply to those frameworks, too, then, of course.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: