>Theoretically this is the best scaling solution.

Html markup on your pages is probably minuscule after compression (you're using zopfli with 5000 cycles and minifying your html, right?), and amortizing the upfront cost of that extra js over the average number of page views is definitely worse than plain ol static html for your blog 99.9% of the time.

But let's get real; theoretically the best? I doubt markdown is even near the optimum in terms of bits on the wire. Don't even talk to me unless you're writing your own binary markdown serialization format.

Well, with 1 client, you have one machine which renders the page and with 1000 clients, you have 1000 machines which render the page.

The processing capacity depends on the amount of clients.

With a static site generator, the processing capacity depends on your own machines and is independent of the clients.

But yes, for a static site, this just doesn't help much, since every client gets the same data, so why should every one process it on its own.

While you can deploy it with a simple web server, it may not always be the best scaling solution. Consider a website built with true "built" static sites, which do not load any javascript. They make only one request to the web server where as jr makes two on the initial load (and again on each page, though cache helps here significantly).