Why would offloading computation to a heavily-taxed central server speed anything up? It doesn't make much sense. Nor is HTML generation a bottleneck in most realistic applications.
Why would offloading computation to a heavily-taxed central server speed anything up? It doesn't make much sense. Nor is HTML generation a bottleneck in most realistic applications.
> Well, I’ve got a pretty good setup for starters: Fibre, 16GB RAM.
You're using a fairly decent desktop setup, and a top-of-the-line mobile setup, and there's no talk about server-side specs. So yes, it's true that "The premise that server-side HTML generation is faster than client-side HTML generation is simply false." -- in your one particular, very specific use case.
Consider, there is no way for a single users machine to do a Google search in any reasonable time frame. Google search works because they can scale out to enough machines to keep everything important in RAM which drastically reduces the workload per request. They can also cache results.
What realistic, year 2016 HTML client is so slow that it can't run 100K or so of string interpolation in a millisecond or two? Quite aside from the supposed benefits of performing computation on a server, the idea that web applications are bottlenecked by HTML generation is already absurd.
http://jsperf.com/dom-vs-innerhtml-based-templating/1079
It looks like mobile chrome can perform 500k string interpolations in a second, each one being about 500 bytes. So the time for 100 kilobytes would be approximately half a millisecond.
Server side generation helps when there is a large amount of application javascript that needs to be downloaded before rendering can begin on the client. Having some html bootstrapped from the server means that the user gets a faster first paint time (though the page is admittedly non-interactive) which gives the impression of a faster page load.