Having built a rather large SPA with Knockout, these are advantages I've found with React:
1) I don't have to worry about whether a property should be observable or not.
2) When changing a property from non-observable to observable, adding parens to most (or all) references is a burden
3) Screens with a large amount of state become difficult to manage and reason about with knockout. Should I use .subscribe, .computed, .pureComputed etc. With React, call .setState, and write plain javascript for everything else.
4) Mapping large objects to observable view models manually isn't fun and the knockout mapping plugin isn't good. React deals with plain objects.
5) Knockout components perform poorly compared to react components with large amounts of data.
6) Knockout is not intelligent in the way it renders. If you replace the value of an observableArray, Knockout will completely re-render any piece of UI bound to that array. This is especially bad when paired with #5. React does a virtual DOM diff and only renders the bits that have changed.
7) With knockout, I have to concern myself with how to go about importing html templates into my components. React is javascript-only. Just use React.createElement, or JSX if you're OK with transpiling.
8) React tooling is infinitely better. I waste a lot of time trying to figure out why some binding is throwing errors in knockout. I've never experienced this issue in react, especially when using PropTypes.
9) Custom knockout bindings to implement 3rd party libraries can be an absolute disaster - especially when attempting to support 2-way binding. It felt like every custom binding I wrote in knockout was full of hacks and terrible code. I haven't felt this way at all with React, and I only have to worry about binding in one direction.
1) I don't have to worry about whether a property should be observable or not. 2) When changing a property from non-observable to observable, adding parens to most (or all) references is a burden 3) Screens with a large amount of state become difficult to manage and reason about with knockout. Should I use .subscribe, .computed, .pureComputed etc. With React, call .setState, and write plain javascript for everything else. 4) Mapping large objects to observable view models manually isn't fun and the knockout mapping plugin isn't good. React deals with plain objects. 5) Knockout components perform poorly compared to react components with large amounts of data. 6) Knockout is not intelligent in the way it renders. If you replace the value of an observableArray, Knockout will completely re-render any piece of UI bound to that array. This is especially bad when paired with #5. React does a virtual DOM diff and only renders the bits that have changed. 7) With knockout, I have to concern myself with how to go about importing html templates into my components. React is javascript-only. Just use React.createElement, or JSX if you're OK with transpiling. 8) React tooling is infinitely better. I waste a lot of time trying to figure out why some binding is throwing errors in knockout. I've never experienced this issue in react, especially when using PropTypes. 9) Custom knockout bindings to implement 3rd party libraries can be an absolute disaster - especially when attempting to support 2-way binding. It felt like every custom binding I wrote in knockout was full of hacks and terrible code. I haven't felt this way at all with React, and I only have to worry about binding in one direction.