[krainboltgreene]

> Uncompressed matters because it takes a device longer to parse more code

This is...a trivial thing to measure, at best. Engineers write way worse code that will be much bigger targets to care about that will likely never be worked on.

> Particularly in a world where low end Android devices are being shipped with slow CPUs and very little RAM

The benchmarks for this (todomvc for example) aren't egregious, even for mobile devices.

> The real killer combination is React plus a giant blob of state that has to be parsed, and then hydrated into individual elements.

That is a bad end-engineer design choice, you don't have to write react that way.

> But people just don't seem to care.

Because they largely don't need to: Even if the end-engineer wrote and designed things in a performant way, it wouldn't account for the slowness of business process.

[untog]

So I guess the answer is "things are going to be bad, so why bother optimising?". I guess I can't really argue with a self-fulfilling prophecy like that. Not considering the size of a JS library because the business process is slow? Oh... kay? Just feels like real lowest common denominator stuff: why should I do good work when someone else isn't?

FWIW I did Lighthouse audits on React TodoMVC and Svelte TodoMVC In the performance category React gets 74 while Svelte gets 100.

First contentful paint:

React: 3.8s

Svelte: 0.9s

Time to interactive:

React: 4.8s

Svelte: 0.9s

I can't make you care about this stuff but the numbers are very straightforward.