I'm pretty bullish on @MightyApp's approach of cloud-rendering your browser / everything.
At some point, we're choosing where to place the user's low quality (compared to cloud) connection. The worseness is due to flakiness, higher latency, and lower bandwidth.
Moving requests to Mighty's lower latency and higher bandwidth cloud is transformative - if you've ever downloaded a file while SSH'd into EC2, it's a magical feeling. Everything can be loaded near-instantly. Then add aggressive caching, ML-driven pre-loading/optimization, etc.??
Connection flakiness is the main thing that could now degrade experience at time-of-flakiness (vs. time-of-load).
But I suspect for a large (and rapidly growing) % of users, the experience of Mighty will be better overall in spite of that dynamic.
Impact of cloud rendering, de/serialization and mega CPU/GPU usage is possibly even bigger. There's some interesting extreme things that could be done to optimize/cache/pre-compute components of these operations when doing it at scale, too.
Some interesting concerns expressed in this tweet & parent tweets of this thread: https://twitter.com/Jonathan_Blow/status/1387530112959057920
I get the lens that it's escalation of complication, overengineering instead of optimization. But another lens - it's a step to simpler web-native apps that don't need to be architected around a slow flaky wall. We can choose to have the interaction loop reach into the cloud (!)
You can follow @bcjordan.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: