[eyelidlessness]

I'm open to the possibility that I'm that wrong in my understanding, but this didn't help me understand any better at all.

The technique does sound similar to me. Both (as I understand it) maintain a representation in memory of the final rendering and use a diff to determine which parts of the rendering to perform. The "virtual DOM" technique isn't strictly tied to a browser DOM, though the term is a reference to that, and React's (in particular) has been adapted to many other rendering targets.

I'd be happy to learn more if you'd be kind enough to explain what I misunderstood.

[c-smile]

virtual DOM implies DOM existence.

DOM based systems use so called retained mode rendering. But this one uses something that can be classified as immediate mode rendering.

Check https://docs.microsoft.com/en-us/windows/win32/learnwin32/re...

[barrkel]

A virtual DOM doesn't necessarily imply DOM existence; I don't buy that. It really depends on how persistent you want your "virtual" to be.

A virtual DOM, to me, means that the application renders by, every time, constructing data structures which are handed off to be reconciled with the display.

If, as in an HTML application, you render by means of a retained mode real DOM, then the reconciliation is via comparison of the virtual with the real. But that's not the only way to handle the output of the construction of a virtual DOM; it could figure out how those structures intersect with the dirty rectangle/s, and only render the subtree of the DOM which applies.

rxi's technique resembles a virtual DOM of depth 2 (1 root and everything is a child) and absolute positioning, though it's even closer to an OpenGL display list or combined vertex & command buffer. For that reason, I think it's a little bit of a stretch; not on the virtual DOM angle, but on the not particularly DOM-like nature of the drawing commands.

[c-smile]

> A virtual DOM doesn't necessarily imply DOM existence;

That's wrong. virtual DOM is always a parallel structure to real DOM - projection of it. That's by definition of it.

From vDOM authors: https://reactjs.org/docs/faq-internals.html

> The virtual DOM (VDOM) is a programming concept where an ideal, or “virtual”, representation of a UI is kept in memory and synced with the “real” DOM

[atlantique]

I get the feeling you're reading this too literally. I think eyelidlessness is talking about using a technique that is analogous or similar to that of a virtual DOM. Nobody is talking about an actual DOM.

[eyelidlessness]

That was my intention yes.

[eyelidlessness]

> virtual DOM implies DOM existence

No, it doesn't. I addressed this in the comment above. React's virtual DOM has been used to render:

- Plain HTML (e.g. server-side rendering) - Native UI framework objects (e.g. React Native) - Text-based interfaces (e.g. Ink) - Smart TV devices (e.g. Netflix's Gibbon) - Browser `<canvas>` elements - Markdown formatted text

And a whole bunch of other targets.

> DOM based systems use so called retained mode rendering. But this one uses something that can be classified as immediate mode rendering.

This seems orthogonal to the question? I'm not trying to be difficult, I sincerely don't understand why this would mean the two are "not even close".

[c-smile]

> Native UI framework objects (e.g. React Native)

React Native uses DOM, the only nuance is that that DOM is a tree of native widgets/windows which is a perfect DOM.

Again, virtual DOM is a projection of real DOM in one form or another. It could be a tree of anything that can be represented by attributed nodes and leaves.

DOM tree has nothing with rendering and pixels, that's why "not even close". By using virtual DOM you can update (by diffing) some tree that even has no visual representation in principle - it is pure data structure. Think about abstract XML config that can be reconciliated with its virtual DOM.

[eyelidlessness]

I think you're using a term in a way it wasn't meant to be used. I tried to give this the benefit of the doubt, I did searches for uses of DOM outside of HTML and XML documents, and it's just not a term that's used generally for any tree representing nodes and leaves. There are much more general terms for those kinds of structures, and pretty much any program which maintains or creates structured data has some kind of representation of data with those kinds of relationships. But the DOM, as defined by the W3C:

> The Document Object Model (DOM) is a programming API for HTML and XML documents.

I was unable to find any other usage.

In reality, I think it would be more accurate to refer to the virtual DOM (at least React's, I haven't spent much time familiarizing myself with other implementations with the same naming) as a virtual output data structure, where the output may be rendered to a screen, it may be rendered to a string serialization, or any other output... but the role it plays (when it performs well) is to optimize output over time by minimizing changes pushed to its destination. One of those output targets is the DOM.

You chose to respond to one of my examples among many non-DOM React renderers, but another one very much has everything to do with rendering and pixels, and that's canvas.

And pixels, to a software, are just another data structure. Software doesn't emit light from an LED or a diode, it just provides data to a hardware which produces physical side effects.

Honestly, this has been an enlightening discussion, but primarily because I've been reminded that my instincts for engaging dismissive comments on the internet are there for a reason. I don't hope to convince you, I don't think any further engagement would be productive, have a nice weekend.

[c-smile]

> virtual output data structure, where the output may be rendered to a screen.

Sigh. Virtual DOM has nothing with rendering.

Virtual DOM was introduced as a lightweight construct to generate and modify tree of nodes.

When the structure is generated it is used as a prototype for updating "master" DOM (or any other tree of nodes).

Any modern UI system is a tree of widgets/windows - child has one and only one parent. So vDOM can be applied as to HTML/XML DOM as to native UI tree of widgets/windows. That's why there are React, Native React and my native implementation of React in Sciter (https://sciter.com/docs/content/reactor/helloworld.htm) for that matter.

Just treat "DOM" as a short name for tree of nodes where each node has a) tag(or type or class) b) collection of attributes and c) collection of children. Nothing more, nothing less.

In any case, I have no idea where here is the place for "grid of pixels ".