It would be nice to see some more numbers, e.g. page size, load time, etc. (and perhaps some critical analysis of the cost you have to pay in the transition period, where your clients for example need to load both frameworks).
"In converting Pinners’ profiles to React, we’ve seen consistent performance and engagement improvements. Performance and engagement metrics each have increased 20 percent."
3 years ago React didn't exist. 2 year ago Angular didn't exist.
Apparently there's still a lot of room for improvement, and much as I'd love for things to settle down soon, I've been very happy that I'm not stuck with jQuery or Backbone as the only tools in my belt!
> 3 years ago React didn't exist. 2 year ago Angular didn't exist.
Not to nitpick, but React has been around since summer 2013, and Angular 1.0 was released on June 14, 2012, so these libraries have definitely existed for more than 3 years. That said, I think that plays even more to your point that there are 3+ years of positive changes to be gained from switching from Backbone to React.
That's not necessarily what he's saying. If React was a paradigm shift (and I believe it was), Backbone can still be good and it's possible it improved in the interim. But it doesn't change that for many of us it's just not interesting anymore.
What surprises me is that you're so uppity about 'defending' Backbone. Nobody is saying it's shit and anyone using it is an idiot. It's just that many of us prefer what came after. It warrants, at most, a discussion as to why this is the case, but I don't see how it's worth any kind of argument.
It's attitudes like this that are getting us into this mess.
If a framework's only been around for a year, which means nothing serious has been written in it, how can you know its limitations? It's appropriateness for large code bases?
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.
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?
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.
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.
No... React is a fundamentally new way of working with the DOM, normalizes many cross browser pain points, and allows one to write their UI declaratively such that total control is retained and state mutations are predictable.
No other major view libraries had successfully done that before React was released. I've used angular and ember as well - their view layers suck.
It ensures that any browser that isn't from google, apple, mozilla, or microsoft in the last year will simply not work, avoiding them significant support burdens!
