[ethbr0]

> Why make the client go read a bunch of information piles to re-assemble Humpty Dumpty every goddamn time they want to view the homepage?

Correct me if I'm wrong, but originally it was because "servers" had order-of client compute power. Ergo, it was necessary to offload as much compute to the client as possible.

And then in early js era it was because network latency and bandwidth limitations precluded server-client round-trips for anything user-interactive.

Now, we've got surplus compute and bandwidth on both sides (order-of text payloads), so caching architecture and tooling become the limiting factors.

[bob1029]

> "servers" had order-of client compute power

Still do. Biggest difference: If you intend to serve the same complexity of web experience today that you were trying to serve 20 years ago, you will find a single MacBook would likely be enough to handle the traffic. The challenge is that we've taken advantage of the exponential compute growth over the years and now it feels like we still have the exact same scaling issues on the server relative to the client.

If you constrain your product & design just a tiny bit, you can escape this horrible trap and enjoy those 4-5 orders of magnitude. If you design your website like Berkshire Hathaway or HN, you are on the right power curve. Seriously - go open Berkshire's website right now just to remind yourself how fast the web can be if you can lock that resume-driven ego crap in a box for a little bit.

[NikolaNovak]

It's very fast. It's almost unusable on a phone. That's not necessary though - I don't think you need much fanciness to make those tables not look teeny on the phone, just a little less pixel and size hard coding I think?

[bob1029]

I am 99% sure you could solve this with a media query and some CSS totaling no more than 1KB.