I'd chalk it up to a difference of opinion then - I like simplicity, but I'd take verbose clarity over it any day. Having to explain to newer engineers the nuances of hooks (and the permutations required to wrangle them in) is harder for me than saying "this exact lifecycle method is what you're looking for, take a look at its documentation".
I don't entirely agree - the old React way was verbose and explicit about when events are executed. This allowed developers to more concretely reason about logical workflows in applications.
With hooks, we traded verbosity for a single interface that does it all (assuming you know how to hook up your dependencies correctly, or compose helper hooks to manage state comparisons). Hooks allow you to do mostly anything lifecycle methods did, but they're a lot trickier to reason with, review, and develop.
This all goes away if all your developers are functional maestros - in practice, it's lead to buggier code across our various frontends.
These effectively boil down to ROI - it's tricky to quantify what return a tool will give, but its even harder to quantify the cost of switching over. At a big enough company, most will shudder at the thought of a massive migration without an equally passive payoff.
In a perfect world, things would be like you describe.
Unfortunately we live in a diverse landscape of browsers and devices, many of which have not been updated in quite some time. Factors ranging from IT policy at older companies, to geographical limitations, may prevent many users from upgrading to the latest and greatest.
Some companies choose to cut their losses, and support only certain browsers - these can get away with less compilation and polyfills. Other companies may be targeting these specific segments (such as B2B), and can't get away with such a luxury.
There is value in 'ranking' things like books and authors: It may serve to emphasize a point someone is making about their relative importance or impact.
It's helpful to have some sort of comparison, even if they're imperfect or highly subjective (as historical observations often are). With a more cynical take, we can perhaps call it analytical clickbait.
Even with positive intentions, I'm not convinced this will solve the problem in any meaningful way. Turning off likes might be perceived as someone being unhappy with their social media status relative to their peers (ie, not getting as many 'likes' as their friends), which signals its own stigma.
Users will be forced into a new dilemma: Enable likes and accept the 'social media pressure', or announce to everyone that they harbor some sort of insecurity about their social media status by turning them off.
Certainly true, but it doesn't counter the original claim: Anonymized telemetry collection with proper privacy considerations can have a net positive impact on the product.
+1 to this. As long as proper privacy concerns are addressed and the data gathering is imperceptible to the product experience, telemetry signals are immensely valuable for improving the product in a variety of ways.
The title requires context - although given recent events we can infer that it is referring to the specific mutation seen in the UK. This particular mutation is of note since it has postulated as being more transmissible than other variants.
The headache doesn't come from building out this 'simple' bare bones solution. It comes from making it play well with the larger ecosystem you're integrating it with, and committing to supporting it for other engineers. All of a sudden, your job description starts to change and you're working well out of your scope.
These managed solutions can provide value for large companies, especially ones that fall into a DIY trap.