The benefit of JS comes in incremental updates. When you update that list with a new item, you can use optimistic update and small payloads in JS, while in HTML you have to load the whole page again, which is slower.
The main issue I have with this idea is that in practice I've almost never found the difference in payload to matter all that much, even on bad connections.
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.
It's not the payload size that matters really, but the latency of requests which you have to wait between interactions, making the UX synchronous and slow.
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.
> It's not the payload size that matters really, but the latency of requests which you have to wait between interactions, making the UX synchronous and slow.
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.
Firstly, the application I was talking about[1] didn't have real updates.
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.
