I remember the concept of the virtual dom had to be explained very carefully so people understood why it led to more efficiency when rendering (e.g.) scrolling content.
Is there a technical trick that one takes that can beat a virtual dom use case? What is it?
Yes, it's an easy trick: just rerender the tiny parts of the DOM that actually need to change. Like Svelte does, only with run-time magic, instead of compile-time magic.
The virtual DOM doesn't really lead to better efficiency, that's a bit of a myth. It's really a UX tool: it means that you can treat rendering as a pure operation (i.e. (state) => UI), and recreate as much of the UI tree as you like whenever you want, without interacting with the DOM directly. Then, at a different point in time, you can diff that virtual tree with the real DOM tree and only make the necessary changes.
This is always going to be slower than a framework like this or Solid or Vue or whatever, which just skips to the last step and only make the necessary changes in the DOM.
Another way to think about it if you're familiar with different forms if GUI rendering is that React is an immediate mode abstraction sitting in top of a retained mode system. In React, theoretically, the render functions could run at 60fps, constantly churning out the same values. In practice this isn't very performant, so React has its own rubrics for when to rerun the render functions, but that's why, for example, it's fine for React to do its weird double-render thing in dev mode. However, at the end of the day, the DOM doesn't work like that, so React needs to diff everything back into DOMland.
Is there a technical trick that one takes that can beat a virtual dom use case? What is it?