Increasingly distracted by the Performance Inequality Gap: the difference between those in the high-performance bubble thinking they're increasing richness without decreasing reach, but who are actually tanking reach by making content inaccessibly slow.
Users with the fastest devices and networks -- which includes ~all developers and business decision makers -- are leaning into technologies (JS) that, by their very nature, are decreasing the reach and usability of their services for users outside the bubble.
These devs & managers benefit from the Performance Inequality Gap in many (often indirect) ways, but not nearly as much as their now-margninalized users (and their businesses) lose.
JS-first moves services away from a Pareto frontier. If they had continued to produce their services with ~mostly HTML, they'd maximize reach at a cost to richness. By moving it to ~mostly JS, they *think* they're keeping reach -- it's on the web -- but that's not what happens.
If each KB of JS had the same win in richness as the reduction in reach, they'd be at the frontier, just at a different location. Instead, the marginal KB added by Babel/Webpack/NPM/React/etc. is *almost never* an equivalent win in richness as the reduction in reach.
The cumulative impact is that the web reaches fewer people...and that's not a crisis for folks inside the high-performance bubble because they've got theirs.
I got distracted by this when thinking through teams I've worked on/with which had slow DBs and servers vs. bloated frontends.
Why does the former usually get fixed but not the latter?
Why does the former usually get fixed but not the latter?
Answer? Slow DBs are equally slow for everyone. The server boundary is a *class solidarity boundary*.
JS has broken the "we're all in it together" aspect of frontend.
