Hacker News Reader

Comment by whoisthemachine | Hacker News Reader

The basic premise seems to be that AngularJS can be just as performant as ReactJS if you do your homework and avoid common pitfalls of AngularJS.

I would argue that the beauty of ReactJS is that it doesn't have any gotchas. It's performant without needing a deep knowledge of the framework.

View on HN

> The basic premise seems to be that AngularJS can be just as performant as ReactJS if you do your homework and avoid common pitfalls of AngularJS.

While AngularJS(1.x) is a bit faster now, your comment is a bit like saying Ruby can be equally fast to Java if one does it homework.

AngularJS has architectural problems that can only be reduced if one doesn't use much of angular features(scopes,watches) inside directives(which means writing components in pure js). So it takes a huge effort to make angular fast in general. That's the reason why they are creating an entirely new framework with version 2.x (which I believe is a mistake, Angular 1.x despite its flaws was pragmatic, 2.x isn't).

React is faster for a few reasons: there are no templates in react, everything is js code React does all the heavy computation outside the DOM so manipulations are minimal and there is no two-way data binding by default, the data flow is unidirectional.

Obviously the angular team wants the same stuff since it has proven it is a better architecture.

> AngularJS has architectural problems that can only be reduced if one doesn't use much of angular features(scopes,watches) inside directives(which means writing components in pure js).

That's an interesting piece of advice there. Could you go more into this?

We've found this out at one of my contracts. We've moved off of the typical $watch/$apply model for our directives and replaced it with a simple observable solution like Scheming (https://github.com/autoric/scheming). Our components are always watching attributes on our Scheming models, which are outside the digest cycle. It speeds things up, and is much nicer to work with IMO.

Given the above discussion about the great performance differences largely being rectified by using angular's `track-by`, I think we can rule out templates as a major driver of performance grief. Templates are usually compiled into native javascript code once (or at least, can and should be), so I really don't see how there should be grand differences between what React is doing and how template processors work.

This, by the way, is an EXCELLENT example of the kind of arguments that have come out of the React.js camp that give me a lot of pause. There's radical differences made in how frontend applications are developed with React, and the primary selling point that I kept hearing was "embrace it, the performance difference is HUGE!". Then as arguments come out about how the performance differences have caveats, the arguments switch to "...well this is how we should be developing, for X, Y, and Z architectural reasons". I'm not saying that X, Y, and Z aren't valid discussion points, but it's been wrapped up in so much pseudo-technical FUD, and that's pretty unfortunate.

Signed, Recovering Template-Aholic

> Templates are usually compiled into native javascript code once

no they aren't.

> (or at least, can and should be)

not by default. React doesn't have templates at all ,so case closed.

> no they aren't. says who?

says the angular team that wants to copy how react works and ditch old angular 1.x templates. Why do you think they are creating an entire new framework? because the old version was good enough? no. 2.x means the whole 1.x was an architecture mistake.

Okay, but react has a bunch of performance and design pitfalls that one could fall into just as easily as not compiling templates. In fact, probably easier to fall into, because compiling templates is a best practice thats built into scaffolding libraries and discussed all over the place.

React gets faster if you use it's features. Angular gets faster if you don't.

React just passes the gotchas to you in architecture - if you make a mistake, it increases the likelihood of the pain down the road. It also is more complex in required build tooling.

That is not to say that it is a good or bad thing - each person's/company's needs are different. I use both React and Angular - I am a lot more performant developing with Angular due to exposure to it the past 2 1/2 years, but I like both libraries.

Hopefully that means the gotchas will be more visible to everyone, but obviously that's dependent on the direction of the architecture.

ReactJS is also a UI framework. AngularJS is a giant beast that literally does everything you need. They are not comparable, with the complexities of things like DI and stuff of course one of easier.

> I would argue that the beauty of ReactJS is that it doesn't have any gotchas. It's performant without needing a deep knowledge of the framework.

shouldComponentUpdate is just as "deep" as this Angular optimization.

Just use PureRenderMixin for all components and you never have to implement shouldComponentUpdate.

shouldComponentUpdate is generalizable across any type of component. The angular thing looked like something array specific.

Reply on news.ycombinator.com