4 ms·

The VDom was never intended as a performance optimization over direct dom manipulation. It is a tool to make functional reactive programming style _almost_ as

The VDom was never intended as a performance optimization over direct dom manipulation. It is a tool to make functional reactive programming style _almost_ as performant as direct dom manipulation. The comparison that's relevant here is, how long does it take to repaint the view if I recompute the view as a function of my state every time my state changes? Compared to rebuilding the dom tree on every change, using a vdoms and diffing offer a huge speedup. Using jquery/vanilla js to update thr dom in an adhoc fashion in response to user input (when the user clicks "next", then add a class to this dom element, remove this other element from this other random place...) has always had faster runtime, it's just more likely to be coded wrong. FRP is an abstraction that makes writing and reasoning about correct UIs easier. Vdom is a technique that makes this abstraction practical.

nailer 4y ago
The link in the previous comment explains why the virtual DOM is overhead, and you haven’t responded to that. Svelte and other current gen compiler-based approaches allow FRP and do not require a virtual DOM.
peoplefromibiza 4y ago
> how long does it take to repaint the view if I recompute the view as a function of my state every time my state changes? you don't need vdom to make this fast. you compute your state in whatever data structure you like and then requestAnimationFrame updates the DOM if and where it is needed. VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW.
- anonymoushn 4y ago
  > VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW. It's funny to read this when Google Chrome has constant tearing on Windows.
  - peoplefromibiza 4y ago
    Haven't used Chrome in years, but AFAIK screen tearing is caused by incorrect vsync settings. disabling HW acceleration can fix it because software rendering is synced to the screen refresh rate. if you rendered your web app in an animationFrame in the allotted time (60hz usually, 1/60 of a second) you won't notice any flickering or tearing even without double buffering. modern HW (screens and GPU) use complete frames, so flickering and tearing are not an issue if the writes are vsynced.
    - davrosthedalek 4y ago
      Vsync needs double buffering. You swap the buffers during vsync to kill tearing. You will have tearing whenever you update the currently scanned-out buffer (except when you do stuff like racing the beam).
- Rapzid 4y ago
  The vdom is the state that gets sync'd to the dom.
  - peoplefromibiza 4y ago
    no, the VDom is a virtualization of the DOM structure in the form {tag, [attributes], [children]} but your application state could be whatever you want, it doesn't need to be in the same shape of the DOM the only problem VDom really helped with was DOM diffing, but browsers are fast enough nowadays that it's not a big issue anymore.
- maccard 4y ago
  > VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW. Double buffering still has a huge appeal on modern hardware - tearing. At 144Hz/fps, a single frame is 7ms, and at 30, a single frame is 33.3333ms - the margin for error is significantly lower. At high refresh rates, I'd rather an extra frames latency to tearing.
  - peoplefromibiza 4y ago
    browsers have been doing smooth 60fps rendering for at least 5 years now, but you'll find stackoverflow threads about it dated 2015, they can do 144fps on much more powerful and better supported HW accelerated devices in 2022. or to make it more clear: VDom is unnecessary because the browser engines have adopted optimizations that made it obsolete, just like many rendering techniques are not used anymore because the HW implements them in a more efficient manner. For fast rendering speed in browsers, support for HW acceleration has done more than anything else combined.
    - PaulDavisThe1st 4y ago
      You're talking past the GP. Double buffering is still widely used by native code (e.g. inside the browser, inside video games, inside native toolkits). Ergo, "VDOM is obsolete the way that double buffering is" makes no sense. OTOH, "double buffering from code running in the browser is now obsolete" may make perfect sense, following changes in how the browser itself interacts with the HW.
      - peoplefromibiza 4y ago
        I think we're simply lost in translation, I'm no native speaker and sometimes I don't make myself clear. AFAIK (not worked on a game in years) double buffering, when I first heard about it, was used to overcome a limitation of the HW, we had graphic/video cards (when I started programming EGA was the standard), GPU did not exist, the amount of memory was limited, data transfers were slow, double buffering meant having two in memory buffers, the active one and the next one, being built in the background, that were alternatively sent to the graphic card. Then VGA added page flipping, you could write two buffers in the graphic card memory and instruct the card to swap the active page by flipping a bit in a register during vsync and then write the next frame in the inactive page. From then on things have improved exponentially, to the point that now GPUs can buffer multiple high res frames, so while frame N is being displayed, the CPU can elaborate frame N+1 or N+2 or even N+3 on some GPU. The framework configures the GPU to automatically swap frames (usually in a FIFO queue) on vsync. I think in Vulkan this workflow is called swapchain. HW implemented what was possible only in SW, double buffering is still in use of course, habits die hard, but the issue it solved is not remotely as bad as it used to be. VDom followed the same path, it was invented to overcome a browser's limitation: DOM access was painfully slow, especially on legacy browsers like IE. Now they are fast enough that VDom, even though technically still largely in use, is not an hard requirement to make fast DOM updates like it was 10 years ago. It stayed there in many frameworks, IMO, because you'll never know what HW/SW combination your users are running, backward compatibility, "if it ain't broke, don't fix it"
edflsafoiewq 4y ago
There's reasons more fundamental than speed you can't just blow away the DOM and recreate it all the time. You'd lose stuff like the user's selection, the contents of forms, etc.
acdha 4y ago
> The VDom was never intended as a performance optimization over direct dom manipulation. This is untrue as written after a decade of fanboys making this exact claim. I think your point that it’s an optimization for a particular style is correct but starting with this encourages knowledgeable readers to skip your comment.
jesse__ 4y ago
> The VDom was never intended as a performance optimization over direct dom manipulation. Performance was definitely it's primary purpose. Remember Flux? THAT was the architecture that introduced FRP to the masses (based on the Elm architecture). The VDom was invented because large dom trees were too slow when you got to thousands (maybe tens of thousands, I forget) of nodes. Which is hilarious if you think about it .. somehow the C++ DOM update loop was slower than someone clever doing it in single threaded JS. > Using jquery/vanilla js to update thr dom in an adhoc fashion in response to user input [...] has always had faster runtime This is very incorrect. > it's just more likely to be coded wrong. While not outright wrong, I find this somewhat debatable. React is pretty complicated these days and it's quite easy to get tangled up if you're not conscious of what you're doing. FRP isn't a silver bullet.
- tobr 4y ago
  The point of virtual DOM is correctness, not performance. The reason performance is so often discussed in conjunction with virtual DOM is exactly because it involves so much overhead, making performance optimization much more important. Carefully handcrafting the minimum number of DOM manipulations for a given state change makes it possible to run much less code than virtual DOM needs, but it’s a nightmare to work with.
  - jesse__ 4y ago
    The point today, yes. The point when it was invented, no.
    - tobr 4y ago
      It doesn’t become true just because you keep repeating it. The point was always to allow for an API where you only had to think about how to render one snapshot, and not care about what the previous snapshot looked like. Virtual DOM made that possible, but it was never more performant than just writing the resulting DOM manipulations manually.
      - 4y ago

nailer 4y ago

The link in the previous comment explains why the virtual DOM is overhead, and you haven’t responded to that. Svelte and other current gen compiler-based approaches allow FRP and do not require a virtual DOM.

peoplefromibiza 4y ago

> how long does it take to repaint the view if I recompute the view as a function of my state every time my state changes? you don't need vdom to make this fast. you compute your state in whatever data structure you like and then requestAnimationFrame updates the DOM if and where it is needed. VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW.

anonymoushn 4y ago
> VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW. It's funny to read this when Google Chrome has constant tearing on Windows.
- peoplefromibiza 4y ago
  Haven't used Chrome in years, but AFAIK screen tearing is caused by incorrect vsync settings. disabling HW acceleration can fix it because software rendering is synced to the screen refresh rate. if you rendered your web app in an animationFrame in the allotted time (60hz usually, 1/60 of a second) you won't notice any flickering or tearing even without double buffering. modern HW (screens and GPU) use complete frames, so flickering and tearing are not an issue if the writes are vsynced.
  - davrosthedalek 4y ago
    Vsync needs double buffering. You swap the buffers during vsync to kill tearing. You will have tearing whenever you update the currently scanned-out buffer (except when you do stuff like racing the beam).
Rapzid 4y ago
The vdom is the state that gets sync'd to the dom.
- peoplefromibiza 4y ago
  no, the VDom is a virtualization of the DOM structure in the form {tag, [attributes], [children]} but your application state could be whatever you want, it doesn't need to be in the same shape of the DOM the only problem VDom really helped with was DOM diffing, but browsers are fast enough nowadays that it's not a big issue anymore.
maccard 4y ago
> VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW. Double buffering still has a huge appeal on modern hardware - tearing. At 144Hz/fps, a single frame is 7ms, and at 30, a single frame is 33.3333ms - the margin for error is significantly lower. At high refresh rates, I'd rather an extra frames latency to tearing.
- peoplefromibiza 4y ago
  browsers have been doing smooth 60fps rendering for at least 5 years now, but you'll find stackoverflow threads about it dated 2015, they can do 144fps on much more powerful and better supported HW accelerated devices in 2022. or to make it more clear: VDom is unnecessary because the browser engines have adopted optimizations that made it obsolete, just like many rendering techniques are not used anymore because the HW implements them in a more efficient manner. For fast rendering speed in browsers, support for HW acceleration has done more than anything else combined.
  - PaulDavisThe1st 4y ago
    You're talking past the GP. Double buffering is still widely used by native code (e.g. inside the browser, inside video games, inside native toolkits). Ergo, "VDOM is obsolete the way that double buffering is" makes no sense. OTOH, "double buffering from code running in the browser is now obsolete" may make perfect sense, following changes in how the browser itself interacts with the HW.
    - peoplefromibiza 4y ago
      I think we're simply lost in translation, I'm no native speaker and sometimes I don't make myself clear. AFAIK (not worked on a game in years) double buffering, when I first heard about it, was used to overcome a limitation of the HW, we had graphic/video cards (when I started programming EGA was the standard), GPU did not exist, the amount of memory was limited, data transfers were slow, double buffering meant having two in memory buffers, the active one and the next one, being built in the background, that were alternatively sent to the graphic card. Then VGA added page flipping, you could write two buffers in the graphic card memory and instruct the card to swap the active page by flipping a bit in a register during vsync and then write the next frame in the inactive page. From then on things have improved exponentially, to the point that now GPUs can buffer multiple high res frames, so while frame N is being displayed, the CPU can elaborate frame N+1 or N+2 or even N+3 on some GPU. The framework configures the GPU to automatically swap frames (usually in a FIFO queue) on vsync. I think in Vulkan this workflow is called swapchain. HW implemented what was possible only in SW, double buffering is still in use of course, habits die hard, but the issue it solved is not remotely as bad as it used to be. VDom followed the same path, it was invented to overcome a browser's limitation: DOM access was painfully slow, especially on legacy browsers like IE. Now they are fast enough that VDom, even though technically still largely in use, is not an hard requirement to make fast DOM updates like it was 10 years ago. It stayed there in many frameworks, IMO, because you'll never know what HW/SW combination your users are running, backward compatibility, "if it ain't broke, don't fix it"

edflsafoiewq 4y ago

There's reasons more fundamental than speed you can't just blow away the DOM and recreate it all the time. You'd lose stuff like the user's selection, the contents of forms, etc.

acdha 4y ago

> The VDom was never intended as a performance optimization over direct dom manipulation. This is untrue as written after a decade of fanboys making this exact claim. I think your point that it’s an optimization for a particular style is correct but starting with this encourages knowledgeable readers to skip your comment.

jesse__ 4y ago

> The VDom was never intended as a performance optimization over direct dom manipulation. Performance was definitely it's primary purpose. Remember Flux? THAT was the architecture that introduced FRP to the masses (based on the Elm architecture). The VDom was invented because large dom trees were too slow when you got to thousands (maybe tens of thousands, I forget) of nodes. Which is hilarious if you think about it .. somehow the C++ DOM update loop was slower than someone clever doing it in single threaded JS. > Using jquery/vanilla js to update thr dom in an adhoc fashion in response to user input [...] has always had faster runtime This is very incorrect. > it's just more likely to be coded wrong. While not outright wrong, I find this somewhat debatable. React is pretty complicated these days and it's quite easy to get tangled up if you're not conscious of what you're doing. FRP isn't a silver bullet.

tobr 4y ago
The point of virtual DOM is correctness, not performance. The reason performance is so often discussed in conjunction with virtual DOM is exactly because it involves so much overhead, making performance optimization much more important. Carefully handcrafting the minimum number of DOM manipulations for a given state change makes it possible to run much less code than virtual DOM needs, but it’s a nightmare to work with.
- jesse__ 4y ago
  The point today, yes. The point when it was invented, no.
  - tobr 4y ago
    It doesn’t become true just because you keep repeating it. The point was always to allow for an API where you only had to think about how to render one snapshot, and not care about what the previous snapshot looked like. Virtual DOM made that possible, but it was never more performant than just writing the resulting DOM manipulations manually.
    - 4y ago