Sorry to be pedantic as I agree with your wider point :) but a 56k modem was actually 56 kilobits per second so a theoretical max of 56/8=7 kilobytes/second. If memory serves correctly real speeds were more around the 4-5kb/s mark

There was another article here recently that is relevant[1]

One takeaway was that given a large sample of sites, the baseline size correlates fairly well with how the bundle size scales as projects grow. So if you have a 65kb baseline, you're more likely to end up with a larger bundle size in a "real world" project than if you used a framework with a 5kb baseline. The reasons are not clear (they could be anywhere from direct causation to indirect causes like incidental complexity due to some communities' higher likelihood of using libraries without auditing them), but the results are what they are, nonetheless.

Also, 65kb gzipped means you're running the uncompressed amount of JS. As a rule of thumb, the more JS you're running, the slower the site is going to be. This matters a lot for mobile, where JS execution speed can be absolutely abysmal (on top of slow network speeds, higher chance of resource timeouts, etc).

[1] https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas...

It's all relative of course but wouldn't you agree that 65kB of JS for a page that displays 1 line of text is a lot?

It's also 65kB of compressed and minified JS which ends up being about 185kB for doing absolutely _nothing_.

For comparison the complete jQuery library weights about 30kB compressed and minified.

Because 65 kB is 65 kilobytes, not 65 kilobits.