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.
-
-
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 -
-
-
The conversations I've been having at my new company have been fascinating. "We don't need to worry about the low end, metrics show all our users are using the latest iPhone." "Is it possible that's because nobody else waits around for our multi-megabyte home page to render?"
-
I can't wait to convince somebody to let me see the raw analytics so I can see if there's a correlation between bounce rate and device class. Those might not be accurate, though, as the analytics JS probably hasn't loaded by the time a user gives up!
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.