alt Hacker NewsGood article and I wish this was much better known.
The issue is though that it's too focused on interactivity. In reality, 90%++ of slow sites are not slow because of interactivity really, they are slow because they ship enormous react/nextjs bundles and have extremely heavy hydration work to do.
_so many_ sites have bundles >10MB that need to be downloaded, parsed and hydrated.
I've even seen (many) sites which have multiple SPAs stacked inside of them.
If you're on a slow internet connection and/or CPU the page is basically unusable for many tens of seconds and no amount of yielding post bundle hydrate will really solve that.
Replies
I challenge you to browse the web one week on this laptop part of the current top 10 Amazon best sellers on a gigabit fiber connection and tell me if you still think that this is the problem: https://www.amazon.com/HP-Everyday-Processor-Microsoft-Porta...
Why would a regular React site be so huge?
Maybe they had bundled fonts and images.
The bundle is just the lib plus your files minified.
You want to bundle vs hitting dozens of requests just to get files.
It’s not like React/webpack is a black box doing things I don’t know or want.
Performance: I challenge you to build a complex 3D game in vanilla threejs vs using r3f. useFrame alone is worth it
Since at least Windows 3.1 we all know that cooperative multitasking is a bad idea. But we see a lot of developers use it, even Rust developers who should know better.
99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.