To me it seems just like wasting money instead of using the same money to produce business value.

Apparently some developers cannot do math, salary-per-hour * effort-spent.

I believe the 20 percent improvement in perf and engagement alone justifies the effort. Otherwise, the choice of React in this instance is great because you can fail quickly (easy to learn + very easy to start integrating), therefore being able to stop blowouts before they arise.

The question is if those 20% weren't also equally attainable by improving the existing code instead of porting to a new stack.

What question? You seem to have already decided on the answer without asking anything.

Is it possible to achieve 20 percent improvement in perf and engagement by improving existing code instead of fully rewriting it in another technology stack?

What would be the monetary cost of such decision versus the monetary cost of the one taken?

Which approach would achieve the same value of 20 percent improvement in perf and engagement with lower amount of money being spent?

Did you read the article or just the word "React"? They're incrementally migrating, not fully rewriting the application.

Yes I did, and did not saw the business case (monetary) in the decision.

Well the article is primarily about the technical implementation, not the business rationale. But they still mention the main reasons: engineer productivity, community support, and performance gains. All of those translate to money.

As someone who used to work on large Backbone apps I agree that it's a huge drain on developer productivity -- hard to add features, hard to test, lack of standards, etc. Not to mention the recruiting problem: I would never accept a job offer to work on a Backbone app again.

There are more factors than that - a lot of good developers will bail if there is not progress made on updating the frontend stack, especially if the technology is outdated/problematic to work with.

In addition, it becomes harder to hire if the technology is too far behind. It often is an indicator that the company doesn't invest enough into engineering because they let their state fall into not up to date codebases. This results in vastly increased recruiting costs, time lost, and decreased quality of life for those who stay.

It's not as simple as a direct calculation. It's very misleading to assume that one can simply shift resources into product feature development and not necessarily incur tradeoffs.

Which is why I bet in three years time they will be redoing everything again in Vue.js, or whatever comes after React.

That's fine. My favorite thing about React is that it's not opinionated -- it follows simple, easy to understand conventions that are not unique to React. It's also compostable from the ground up meaning it's easy to use React in non-React code and vice-versa.

I don't think Vue will replace React for this reason (it's much closer to old DOM-munging style) but if something does its much less of a big deal than going from Backbone->React.

I'm sorry but are you serious? Any decent front-end dev should be able to be proficient in React in a week.

Yes, which is why it's easier to find React developers, or what are you talking about?

I think you are confusing proficiency with seniority, though I think good learning curve might also be a factor for the switch.