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.
-
-
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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?
Show this thread -
Answer? Slow DBs are equally slow for everyone. The server boundary is a *class solidarity boundary*.
Show this thread -
JS has broken the "we're all in it together" aspect of frontend.
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.