3 ms·

The premise that server-side HTML generation is faster than client-side HTML generation is simply false. See here for experimental confirmation: http://www.oneb

The premise that server-side HTML generation is faster than client-side HTML generation is simply false. See here for experimental confirmation: http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html http://www.onebigfluke.com/2015/01/experimentally-verified-w... 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.

joekrill 11y ago
You almost confirm his point: > 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.
- JoeAltmaier 11y ago
  The server has to do it for everybody, right? If it scales at all, no server is powerful enough. But mobile makes it more complex.
  - Retric 11y ago
    If you can afford to do X on a server. Then spending 10x the resources to load in 1/10 or better yet 1/100th the time scales just fine. 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.
- jhpriestley 11y ago
  Put some numbers up. This whole debate is driven by so much vague thinking and so many unfounded assumptions. 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.
  - falcolas 11y ago
    Mobile Chrome. https://news.ycombinator.com/item?id=11366272 https://news.ycombinator.com/item?id=11366272
    - jhpriestley 11y ago
      Here's a benchmark: http://jsperf.com/dom-vs-innerhtml-based-templating/1079 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.
takno 11y ago
I'm fairly sure it's to do with lots of developers being scared to write even basic client-side code without loading and calling a bunch of random functions on an 8mb framework. Sadly rather than treating user processors as a sensible saving of server time, developers have been treating it as an all-you-can processing buffet, taking more and more cycles without even bothering to think of a good reason why.
mrsharpoblunto 11y ago
Seems like his benchmark is not really measuring a realistic use case. Typically a client-side rendered application will have a big blob of external script (i.e. the application code) that it will have to pull down before rendering can begin - in his example the client side rendering code is A) tiny, and B) already bundled into the page itself meaning that there isn't going to be any delay on client side rendering once the html is downloaded. 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.

joekrill 11y ago

You almost confirm his point: > 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.

JoeAltmaier 11y ago
The server has to do it for everybody, right? If it scales at all, no server is powerful enough. But mobile makes it more complex.
- Retric 11y ago
  If you can afford to do X on a server. Then spending 10x the resources to load in 1/10 or better yet 1/100th the time scales just fine. 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.
jhpriestley 11y ago
Put some numbers up. This whole debate is driven by so much vague thinking and so many unfounded assumptions. 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.
- falcolas 11y ago
  Mobile Chrome. https://news.ycombinator.com/item?id=11366272 https://news.ycombinator.com/item?id=11366272
  - jhpriestley 11y ago
    Here's a benchmark: http://jsperf.com/dom-vs-innerhtml-based-templating/1079 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.

takno 11y ago

I'm fairly sure it's to do with lots of developers being scared to write even basic client-side code without loading and calling a bunch of random functions on an 8mb framework. Sadly rather than treating user processors as a sensible saving of server time, developers have been treating it as an all-you-can processing buffet, taking more and more cycles without even bothering to think of a good reason why.

mrsharpoblunto 11y ago

Seems like his benchmark is not really measuring a realistic use case. Typically a client-side rendered application will have a big blob of external script (i.e. the application code) that it will have to pull down before rendering can begin - in his example the client side rendering code is A) tiny, and B) already bundled into the page itself meaning that there isn't going to be any delay on client side rendering once the html is downloaded. 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.