[krainboltgreene]

React 16 is 2.2 KB or 34.8 KB if you include react-dom, Vue 2.4 is 20.9 KB, and jquery 2.1 is 28.87 KB.

If you're using a bundler that can create chunks, your user is at best downloading this once in a blue moon.

The reply page I'm using now is 10% bigger total than these packages and has to be pulled every time apparently.

By what metric are these "huge runtime libraries"?

[untog]

> React 16 is 2.2 KB or 34.8 KB if you include react-dom

Gzipped. Uncompressed React is 6.3KB and react-dom is 114.5KB (and of course you're going to include react-dom, how else would you use it?!)

Uncompressed matters because it takes a device longer to parse more code. Particularly in a world where low end Android devices are being shipped with slow CPUs and very little RAM.

The real killer combination is React plus a giant blob of state that has to be parsed, and then hydrated into individual elements. It's a giant, giant waste of CPU time that is acceptable on my iPhone XS, but when I plug in a Nokia 2 it's horrifying. VDOM itself is needlessly CPU intense in many ways.

Even if you don't want to use Svelte it baffles me that more people don't use Preact. 9.5KB uncompressed and it does 95% of what React does. But people just don't seem to care.

[ThePhysicist]

I use Preact for small apps and demos, works really well for that! For larger projects I still prefer the real React library because there are some edge cases where Preact does things differently (can’t remember what exactly but I remember that I ran into some problems when trying to migrate a large react codebase to it).

[pier25]

> baffles me that more people don't use Preact

Or Inferno, or Mithril, or Solid.

[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.