News for hackers. Stuff that matters.
Re:Show HN: Sapper.js – towards a better web app framework by timr on Tuesday January 02, 2018 @01:00PM (#16053725)
Going back to the server for 100kb of HTML and reloading the entire page, as opposed to fetching 10kb of JSON and instantly updating it in place, is a very 2002 way of doing things!

The difference between streaming 100kb and 10kb is small when compared to the connection latency itself. Even on a low-end LTE connection (5mbps), 100kb is 20ms, whereas the latency of a cross-country (US) transit is realistically ~50-100ms. The difference decreases further when you enable server-side compression and start doing fragment rendering, which tends to remove the penalty for HTML payloads.

The argument for react-like technologies is not connection latency, but rather, the hope that you can avoid synchronous connections in the first place by moving your view logic client-side. And truthfully, few client-side apps are written in a way that would minimize payloads anyway. Most people are doing it because they hate working with the DOM and AJAX and server-side frameworks in a mishmash of web technologies, and perceive these client-side frameworks as easier.

Re:Show HN: Sapper.js – towards a better web app framework by GordonS on Tuesday January 02, 2018 @01:16PM (#16053881)
There is also browser caching. So subsequent page loads may not require any new scripts or stylesheets to be loaded, for example, so you're only loading some GZIPped HTML.
Re:Show HN: Sapper.js – towards a better web app framework by noxecanexx on Tuesday January 02, 2018 @03:52PM (#16055499)
You couldn't have said it any better.