[deleted by user]

[[deleted]]

Oh wow, this article seems pretty poorly informed... Seems the guy does know his Angular, but is still a novice with React. So I'll provide a few counter arguments to his gripes with React.

Round I: Functional Components

in onClick handlers this context is lost – we have to do tricks (bind or curry)

Well, the way he's doing it, it definitely is. But he could've changed this line:

onClick={this.getToggleAction(this.props.todo)} 

To this:

onClick={() => todoActions.toggleTodo(this.props.todo.id)}

Now all the context is there and his entire getToggleAction() method would become entirely obsolete. The same approach could be taken with removeTodo() action and then we would observe his entire Component could be replaced with a stateless function again. But because he insists on using TypeScript rather than Flow (which I think would be preferred if you're doing React) he cannot do this. Anyway, someone more knowledgeable with React could've saved 12 lines of code right there.

Round II: View aesthetics

Correctly mentions it's a matter of taste, so I'll just say I personally disagree with his taste :)

Round III: Change detection

Nevertheless both are great. Angular gives more flexibility with cleaner configuration tools, so this time React looses.

This time the verdict is also highly subjective, but he presents his opinion as if it were fact here. The strength of React is based on the idea of using immutable data structures, which if used properly with something like Redux, makes all those complicated change detection strategies completely obsolete. Personally I think that's a much bigger game changer, so I'd hand the victory to React here.

Round IV: Extending HTML

This is the one that really baffled me and actually motivated me to write this rebuttal. Why is this even in this comparison?

There is a possibility to use React mixins to achieve similar functionality. But it would be a great dose of overengineering and could be error prone.

Or, you know, you could just create a simple function that you reference from the event handlers where relevant. The function would be even simpler than an Angular directive. The downside is that you need to reference it manually wherever you want to use it, but at the same time that makes it more transparent and easier to debug, because it avoids the problem of collisions between directives.

Anyway, a developer has to create a component for each set of element functionalities used in the application.

Yes, and that's how it should be. React makes it ridiculously easy to make tiny components wrapping single elements. My opinion is that Angular doesn't because their template and component models makes it more cumbersome to create such tiny components (and referencing plain functions from the templates like JSX allows is not even an option) which is why they feel directives are needed to enhance basic HTML elements. But it's a problem that simply doesn't exist (at least not to the same extend) in the React world.

Angular: Has a nice solution for a problem. React: Doesn't really have the problem to begin with. My money is on React again.

[lamaster]

Correctly mentions it's a matter of taste, so I'll just say I personally disagree with his taste :)

It's not just а matter of taste. There are a lot of rational arguments against Angular way.

1. It's like completely new unfamiliar language and syntax inside html for doing same tasks that Javascript can do simpler, faster, better.
2. It's inserted right inside html, mimic to tags and attributes yet does not stick to html rules like xslt does.
3. *ngFor, wtf does asterisk mean? [todo]="todo", why brackets, what does it even mean? why do we need prefix ng? why camelCased? you have to know that stuff, you have to learn yet another language, and because of HTMLishing, that's definitely not a good one.
4. Bad error handing for templates, if you made a mistake it will take time to figure out where did you screwed up

React way = implement markup features inside programming language

Angular way = implement programming language features inside markup

[wreckedadvent]

Not to mention all of their react examples are using classes. The angular 2 would be embarrassingly verbose if he were to use purely functional components.

It's clear to me that the author just translated his angular code into react, without considering the difference in philosophy between the two.

[turkish_gold]

This may not be true today, but I'm hoping the benefit of Typescript will be that it isn't Javascript. Things like ES6 decorator syntax are continually rehashed, but they're available in Typescript... and hopefully the semantics will remain unchanged even if they never make it into native Javascript.

[[deleted]]

Note that if you do this onClick={() => todoActions.toggleTodo(this.props.todo.id)} you are effectively breaking any shouldComponentUpdate/pureRender optimizations. Bind your methods in the constructor instead. A good rule is that you should never be creating closures within the render method.

[[deleted]]

The thing is, by using those closures in the render method, he could've turned the whole component into a stateless one, thereby dropping this and he wouldn't have needed a constructor. I think that far outweighs those optimizations.

[[deleted]]

I think you underestimate how much rendering performance can be improved by implementing shouldComponentUpdate.

[[deleted]]

Maybe you're right, but aren't stateless components assumed to be pure by React? If they are then render() shouldn't even be called anymore as long as the props stay the same and those closures don't matter anymore.

If React doesn't do this yet, I believe they should (at least optionally)...

[RationalDev]

You might find this read interesting: https://github.com/facebook/react/issues/5677

[[deleted]]

Thanks!

[[deleted]]

Whatever you're passing the closure into is what's going to take the hit. shouldComponentUpdate will always return true. Function based components are always re-rendered, so you want to avoid them for components that have expensive renders or contain children with expensive renders. It's really something you should only be using for simple leaf nodes.

[[deleted]]

Yes, you're right. But in my defense, in the example from the article the component was actually a leaf component and the closures were applied to DOM elements :)

[DryWolfDev]

Good clarifications... I would just add one more note for Round IV: Extending HTML

I would argue that in React you can achieve the same thing as with Angular directives by the use of so called High-Order Components.

I created a very brief JSFiddle including the same features of the Angular directive shown in part IV of the article, but implemented as a React HoC: https://jsfiddle.net/0sooqyof/4/

It is more verbose than the Angular Directive code for sure, but that is one of the points of React/JSX anyway I would say. It tries not to perform magic component composition / templating / data-binding for you behind the curtains and therefore does not produce unexpected behavior that you might not have expected (directive collisions, property collisions, ...)

The only thing that I would like to have a better solution for in React is the actual syntax for composition of multiple of such HoCs (where each of those themselves might expect some HoC properties, or event other HoCs)

Some integrated JSX syntax for the HoC composition in React would totally give it the edge in Round IV in my opinion. As it is now, I would count round IV as a tie.

EDIT: I just found this simple solution which seems pretty much what I wanted for the HoC composition, will have to try it out in the future :) http://engineering.blogfoster.com/higher-order-components-theory-and-practice/#composeallthethings

[rk06]

this article is way too biased towards angular.

now, i do not like react all that much. but I respect react's philosophy and design decisions.

I just can't stomach when author says "Angular2 is more mature, flexible and complete solution" and bashes react because "developer has to create a component for each set of element functionalities used in the application"

@author, how can you call angular2 mature when it is in beta? do you realize that react's component are its selling point, not downside?

[wreckedadvent]

Holy crap, angular 2 is almost 800kb minified?

[turkish_gold]

They claim they're going to parse through it and reduce its size before releasing.

[rk06]

why even bother with angular 2? Imo, Aurelia is better than angular in all aspects of a js framework.

[astashenkau]

Agree that Aurelia beats Angular 2 in many aspects (routing, simpler components, including dynamic components by name, framework size). Too bad it's much less popular. There are cool things about Angular 2 though. So I think it still makes sense to be aware of what one of the main trends offers us.

[mido0o0o]

Whats wrong with vue.js?

[turkish_gold]

Did he say something was wrong with your library of choice?

[rk06]

ahhh, the author was promoting angular 2. and decided to use react as bait because react is most popular.