@cbirdsong@daringfireball Just want to make sure that we're on the same page here: this website – as pictured in the most widely used browser, on the most widely used OS – is complaining about the state of the mobile web?
@andydavies@AmeliaBR The biggest indictment for me was always that corp policy generally rejected devices more than a few years old because the Android and Pixel teams couldn't be arsed to keep supporting those boards and architectures. Much of *that* was downstream of failing to own enough of the SoC IP (drivers, etc.) to do a good job.
@andydavies@AmeliaBR You can still likely find docs I wrote outlining how unserious this all was. Not buying Imagination's IP when it was up for sale...not buying Intel's modem group...not starting on custom SoCs until it was way too late, then continuing to fuck up single core perf...
The thing folks at the low-end are mostly missing out on is performance, which is dominated by combined L1 + L2 + L3 + SLC on-package caches, with process-shrink-driven frequency scaling not far behind:
For the Performance Inequality Gap series, I'm gathering new data points in charts that I'd only talked to in prose in previous years. One of those is the difference between the various market segements looks at by price, with the Flagships clocking the new, unlocked cost of the fastest chip in each line, while the lower-end lines capture the mid-tier and low-end segments from various manufacturers.
The blue line that has never bumped above $375? That's worldwide average selling price.
@dotstdy Yes? Obviously? Caches and associated ARBs aren't free, and in the die shots I've worked through for various generations of Android and iOS SoCs, you can see almost as much ARB space on A-series parts as actual cache circuitry. Shrinks help them too.
These are choices about how often you're going to stall for an eternity, and what else you're going to boot of the die (in Apple's case, the radio that Qualcomm wants to sell).
@dotstdy The important thing that web developers need to understand is that expensive phones are rare, and cheap phones are everywhere. And that cheap phones are *much* slower than anything they've used in a long time.
Discussions of relative L1D and L1P sizings per core across different manufacturers (e.g.) isn't useful detail, so I omit it.
It feels only fair that browsers should detect when you're reading the news in a native app and bombard you with notifications telling you how much better the web version is as you try to scroll.
@maphew@dotstdy And it doesn't even work! I sit with *so many* teams that are beached on the shores of unshippability because their "move fast" stacks only provided a one-time burst of acceleration, rather than sustainable gains in velocity and momentum.
Adding the time folks have to spend remediating these made-up problems to the cost side of the equation makes these "move fast" systems look like what they are: irresponsibily marketed tools for experts in the hands of n00bs.
I've come to understand what's happening in frontend's decade-long failure to deliver decent user experiences as a sort of epistemic closure. I'm calling it "frameworkism", and the epicenter is now React.
Here's a lot of words on why we should all reject it, and what the post-React world should look like:
At absolutely no point in the 2020s should you, or anyone you don't hate, start a project with React.
There are a lot of reasons for this -- that it's legacy tech built for a world where IE 6 still had measurable share, that the Reactor community has been wrong about everything all the time for a decade+, that the money you'll save can be measured in truck-loads -- but the *most* important is that it will opt you out of the godforsaken React discourse.
@mccrodp This will sound glib, but the real tension today is between the assumption of framework-silo'd development and thinking about user needs. They don't *sound* like opposites, but I promise that they are.
The advice I give most teams it to start with user needs:
So bsky's site is...what's the word?...bad, performance-wise. [1]
I pointed this out, and folks asked what I'd do differently. I had to preface the response by saying that you don't start any new projects with React in the 2020s because it was designed for the (early) 2010s and has aged like fine milk.
This drew out a reply by someone saying that *they* start with React, but *they* know what they're doing, and all I can think is "does your boss know?"
You don't need to imagine a conspiracy to suppress the web by slow-rolling important new features when the base-case is that the APIs that *are* implemented are indistinguishable from elaborate practical jokes.