Perhaps surprising: I agree with @slightlylate that the discussion we're having about web performance isn't helping us move forward as a community.
I would be opposed to any analysis that will be primarily used to stack-rank popular frameworks in global terms, and I believe that this kind of analysis is what's causing the current crisis that @slightlylate is referring to.
-
-
The question is rather: how do different TECHNIQUES correlate in different environments: SSR, async code fetching, tree shaking. There's a legitimate open question about whether SSR produces better outcomes in emerging markets at different size ratios.
-
These analyses can be used as the input to smart bundling tools, but only once we start focusing on techniques rather than the number of bytes in libraries.
-
Sounds potentially useful to me. Is there anything browser engineering teams like mine can provide to help enable framework technique experts (certainly not me) to more easily do and leverage such an analysis?
-
Telemetry can help answer the impact of deferred loading, deferred eval, successful use of lazy parsing in different environments.
-
Deferred loading means waiting until the user interacts to fetch and evaluate code, showing a spinner at that point. Deferred eval means fetching code up front as inert content and evaluating it on demand. Lazy parsing means eval up-front but hitting lazy-parse heuristics
-
TTI matters a lot, but so does how long users have to wait for spinners, how much "deferral" techniques trigger lazy jank.
-
Also, how much does "background fetching" affect these heuristics, where background fetch means optimize for TTI but download and eval the payload in the background (again, with the matrix of deferral options)
-
These techniques have different tradeoffs depending on how expensive network is vs. CPU. And sometimes expensive means literal money.
- 5 more replies
New conversation -
-
-
Sure, not advocating for "global" terms. But what about in key cohorts like for users of Android phones in India on 3G networks?
-
It seems to me like a developer targetting a specific audience can make the best possible framework decision by looking at (among other things) hard data about the extent to which others have succeeded in getting great UX for that audience with different frameworks
-
The problem here is that big companies can throw a lot of money at building and using tools that small apps don't have the resources to build or use.
-
We need to look more closely at techniques than frameworks, so that devs can predict what will happen with normal use of a stack, not the best-case-scenario that hugely resourced companies can pull off.
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.