For "application paradigm" my points stand. That's where JS is appropriate. I did say "where appropriate", after all.
> Primary and by far most frequent use case.
In document paradigm.
> And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly.
Not if the client-side routing is done properly. I did say "if done properly".
> Anyone who doesn't support JS to the level you want?
With modern transpilers, you can produce lowest-common-denominator JS. Essentially you are treating JS as a build target / ISA.
> Well, fuck those people, let them make their own wheelchair ramps.
What's the alternative? They can download a native app, but that doesn't work for everyone either (both from the developer and the user perspective).
Primary and by far most frequent use case.
> After that, JS can just keep modifying the DOM based on the data retrieved from API, and never download HTML and construct new DOM again.
And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly.
Anyone who doesn't support JS to the level you want? Well, fuck those people, let them make their own wheelchair ramps.
> If done properly (and that's a big if!), and where appropriate, this can be much faster.
A big IF, indeed.