Well, without getting into details and irrelevant domain specific examples, let's say you want to load new content as you scroll down.

----------------
HTML static content way:

1. The new content will be fetched using ajax.
Already some problems. From the server-side rendering, it needs to fetch it from the DB, then load it in the template. Using django, for instance, the view will fetch it and we'd show it using {{variables}}.

However, to fetch the data using ajax, it's not just the view making a query, it needs to have an API standpoint, i.e. /api/fetch-new-data/. So, already, the code is duplicated. Yes, the server-side could use the same API, but there's always the problem of returning JSON vs django-ORM-queries, etc.

2. Once the data is fetched (say in json), it needs to be rendered. How? Do you simply do a

$.get('/api/whatever', function(data) {
$('.some-div').append('<p>' + data + '</p>');
});

It's fine if it's just a <p>. But usually we'd have a more complex html and thus we'd be using client-side template. So, the server-side templates need to be duplicated. There are various ways to do it, varying from complexity, but there is clearly some duplication here. And, bear with me, it's usually not a simple .append, more javascript needs to be done which can alter the data, etc.

-------------------------
Javascript way

1. Load pure html.
2. Fetch initial data and render it using client-side template. (It can also be bootstrapped since it's in the same JSON format).
3. On scroll, fetch more data, and render it using the exact same code / client-side template.
----------------------

Lastly, bear with me that it's just a simple example. It's rarely 100% static content only. I.e. there would be forms with error validation, etc. If you want to do it the no-javascript way, you need to have it submit, reload the view with validation error, etc. Only then, you can add some javascript to enhance it. Contrast that to simply validate on javascript submit. Yes, obviously, the server needs to validate it, but that's part of the api, nothing needs to be re-rendered.

All in all, if you agree that the same code would do the pre-loading and the dynamic real-time stuff, you usually save yourself lots of headache and complexity.

I believe blogger had that problem as they show different views for the same content. When you switch between views, it dynamically updates it in javascript, rather than doing a page reload. Could it be made better by having a html/css content for no-js browser, sure thing. Would that duplicate the code? Sure thing. And again, there are different varying of complexity. Maybe that example wouldn't be too complex, but it's more code to maintain, to test, etc.

It's a bit late here, but hopefully you understand what I mean. And by the way, I'm still not 100% certain about what's the best approach. I know that I used to be pro html static first for backward compatibility and no-js users, and only javascript to enhance the page. But recently, I've tested it by doing it in javascript on the client and it's seriously so much faster and cleaner.

And yes, there are some good frameworks to deal with the duplication, but it adds lots of complexity. For instance, see airbnb Rendr which try to solve that exact problem that I'm talking about. I.e. being able to load backbone.js on the server during the pre-rendering stuff.