Comment by int_19h
2 days ago
You're correct that the main thing enabled by JS is partial updates, but the fact that it relies on JS is IMO itself in large part due to path dependent evolution (i.e. JS was there and could be used for that, so that's what we standardized on).
Imagine instead if HTML evolved more in the direction of enabling this exact scenario out of the box. So that e.g. you could declaratively mark a button or a link as triggering a request that updates only part of the page. DOM diffs implemented directly by the browser etc.
When that data streams in though, how is a developer defining what it changes?
Or in this hypothetical is the remote server always directly sending HTML?
I was thinking more along the latter lines - i.e. the link/button would specify the ID of the element to update, and it would be replaced with the received HTML.
If we're unwinding back to early 00s though, it could also be fetching XML from the server and then running it through the XSLT stylesheet associated with the current document to convert it to HTML, to reduce the amount of data on the wire.
The specifics could be debated here. But I'm pretty sure that a generic mechanism could be devised that'd adequately cover many use cases that require JS today.