> Also, you wouldn't apply generating html on the server to everything, on the parts that make sense. If you want to use JS to update part of the DOM (e.g. showing an error that passwords don't match), then you'd obviously use JS.

In practice, this actually sucks to do. Now you need to query the DOM to get a handle on all the places you want to inject dynamic parts into. Now you've got coupling between the structure generated by the server and all the selectors in your client JS targeting those nodes. What if your client JS is served from a CDN and you can't guarantee the new version will be served up at the same time the server starts outputting different markup structure? You not only need to keep your code synced in two places, you need to keep the distribution of it synced. If it had all been generated in the client JS in the first place, you wouldn't have to worry about it.

And if an update to that markup arrives from an AJAX request or whatever, wiping out the existing markup as you're suggesting? you lose the dynamic stuff you injected and gotta do it all over again.

> It's completely ok to use the right tool for the right job.

Why is the server the right tool for generating DOM structure, something only a web browser cares about? For static documents, sure it still makes sense. But in the age of the DOM representing an application, people are rightly questioning why you'd ever generate the DOM structure on the server in the first place: it not only causes jank but just doesn't make intuitive sense.