[genezeta]

> I have a hard time understanding how, say, calling 500 methods per second on a DOM object, e.g. `label.innerText = someSensorValueComingFromWebsocketsVeryFast;`, which needs to trigger various events, callbacks, etc... every time could possibly be faster than modifying a pure JS object at the "incoming message rate" and then blitting that object at the screen refresh rate or something similar ?

Updating a value on the DOM 500 times per second just because you can read it 500 times per second falls, again, in the category of writing wasteful code just because it's simpler. i.e. "don't care about performance, just let the browser work".

If you compare code which is initially bad, then sure, a lot of "solutions" will be better than that.

The appropriate comparison for evaluating the value of using a virtual DOM should not be about that, but only about the part you describe as "blitting the object to the screen". You have the data, no matter how, where, or even -to some extent- how often, and you want to put it on the screen.

[jcelerier]

> The appropriate comparison for evaluating the value of using a virtual DOM should not be about that, but only about the part you describe as "blitting the object to the screen". You have the data, no matter how, where, or even -to some extent- how often, and you want to put it on the screen.

But the solution to the problem which is

    how to go from 
      inputs (which you don't have any control over) 
    to 
      "You have the data, no matter how, where, or even -to some extent- how often, and you want to put it on the screen"

will pretty much look like a vdom, no ?

[genezeta]

> will pretty much look like a vdom, no ?

Not necessarily.

Maybe you can find some rendering comparisons from a few years ago. There was some "demo" called DBMonster or DBMON that showed the performance of updating a large amount of values on a table in a web page. The thing is a lot of different implementations were then written by many people using many different frameworks -including many using a virtual DOM and many not using one- and also even some "vanilla" implementations. I don't suggest it for the performance comparison -which you can of course look into- but, more in line with the question: it may be a good way to find a number of different approaches.