Secondly, no one stops you from doing incremental updates with HTML except they way you design your data structures and UI.
In fact, HTML has something that JSON doesn't. Semantics. This means you can create a generic setup for incremental updates based, say, on element IDS.
---
[1] https://hackernoon.com/10-things-i-learned-making-the-fastes...
In some cases, even sending the entire HTML document and diffing on that using morphdom (because redrawing does bring noticeable cost rather quickly) was a viable strategy even compared to the most optimal json payload.
I'd very much like to see some examples that prove me wrong though, because while I've done some experiments, I might be underestimating how complex many web apps are. It's mostly that the apps I built in hindsight were often better off with a more old fashioned server-side, morphdom, turbolinks (or maybe intercooler?) type approach.
Good examples are, well, almost any modern and popular app. Like Trello for example. Users spend lots of time on the same page making micro-interactions, creating cards, moving cards around, adding tags, etc. You want to make the in-app experience as flawless as possible in these types of apps, and the initial JS size doesn't matter so much especially when it's cached. There's also lots of shared state and you might be saving multiple things on the server at the same time or uploading multiple files in the background while editing other parts. You might want to store data offline and sync later to the server. Once you have decent complexity, JS app with framework such as React help a lot.
I'd use websockets if that was an issue. That said, Trello is a good example where I do agree a web app is a great solution.
In other words, when the web is architected as intended, it works fine, even with javascript.
Imagine that. It's like the problem isn't javascript per se, but unnecessary complexity.