>GUI apps have struggled with this as well

And when we made mistakes there, it was usually because we took short cuts instead of respecting clean abstractions.

>So you have to think of all the machinery to change as few DOM nodes as possible.

This is where I get off the train in regards to JS frontend frameworks. We should know the state our data. We should also know the state of our display components, whether they are canvas elements rendering more complex data or mere tables. KISS principles apply here.

"All the machinery" of a framework isn't necessary to handle the synchronization between the two. Especially when it mandates ridiculous build steps, thousands of dependencies, opaque "magic", huge blobs of minified JS and loading spinners.

>The difficulty usually comes from people mixing up two concepts: the state of data, and the state of the UI.

Agreed 100%. Which is why I like the <template> element. It is a dose of sanity allowing explicit separation of code and document. I suspect this is the other poster's objection to HTML inside of JS.