Hacker News Reader

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.

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.

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.

> 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.

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.

The point today, yes. The point when it was invented, no.

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.

Then let an old fogey make it more clear: browsers repaint/recalculate if you read after write. This required batching writes separate from reads if you wanted decent performance on older browsers and especially on older machines.

Reading an element property, adding/updating a nearby element, and then reading another element's property took FOREVER. Enter the virtual DOM. Since it did not engage the actual rendering engine, the reads and writes did not trigger reflow. At the end of the code segment, the actual DOM actions became effectively write-only. Even though the virtual DOM was slower per access than the actual DOM, the end result was a MASSIVE speed up.

This message brought to you by someone who honed their skills for a decade to batch their reads and writes in vanilla JS only to have those new-fangled frameworks take care of it (and data binding) for you. Jerks.

Dude, this is awesome.

So what you're you saying is that at the granulatity of a single tick a VDom increases performance significantly due to not having to wait for the browser to recompute the dom after writes.. correct? It effectively batches writes, and thus the need for the renderer to get involved, which increases read throughput because reads block till after the DOM was recomputed. And the DOM is recomputed on every write thats followed by a read.

Makes a lot of sense, thanks for the input; I was completely unaware of this case. Any idea if this is still the case? Do you happen to remember what browsers and/or hardware that saw dramatic improvements (CPU gen would be great)? I'm thinking of doing some deeper perf investigation/spelunking on the subject to satisfy my curiosity. I remember things one way but a lot of people seem to think the opposite..

The view is recalculated/re-rendered/repainted. The DOM is the single-threaded-access data structure that the rendering engine ties into.

Part of the browser API is querying all current CSS properties of an element, e.g., getComputedStyle(…). The only way to get this is by having the layout engine do all its work, so properties like height and width can return accurate info.

Most virtual DOM implementations just skip parts of the API like this. At best, they make an educated guess without hitting the actual renderer. Or they just allow a pass through to getComputedStyle(…) and warn you away from using it due to performance concerns.

It's all smoke and mirrors topped above a bed of lies.

How big of a role does React's ecosystem(libraries,plugins,developers) play than say for the aforementioned(debated) performance/stability/security etc. in a someone choosing it over Svelte?

> 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.

> 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.

> 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.

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.

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.

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"

> 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.

Not sure why you'd call this an "exponential improvement". Using more than 2 buffers increases display latency, which for most (not all) purposes is undesirable. Double buffering (that is, just using an active/inactive buffer) is almost always the best thing to do, regardless of where the memory is located or who is responsible for the buffer swap.

> 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.

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.

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).

The vdom is the state that gets sync'd to the dom.

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.

It feels nicer to use functional components with declarative state than set dom attributes imperatively.

Plenty of libraries have functional components and a react-like experience without the need for a virtual dom. Lack of vdom does not necessitate imperative dom usage.

It’s the same observation TDD makes. If you can figure out what a sane interface looks like, it doesn’t matter how it’s implemented underneath. You might even want to change your mind for performance or new feature purposes.

lit-html is similar to the render method of a react component, uses a declarative html'esque syntax, and doesn't use a VDOM AFAIK.

No one is saying update DOM elements manually. They're saying there's better strategies for view libs than VDOM.

That's kind of an entirely different paradigm, considering lit is a Custom Elements framework.

I don’t really understand what you’re point is? Isn’t the ‘dom is slow’ thing about comparing to e.g.

- creating actual DOM elements during render and diffing that with the DOM, or

- using the existing DOM as the thing being diffed against your new vdom (slow because calling into the browser many times may be slow and you need to check eg there aren’t attributes to be removed from your elements)

Perhaps it’s also necessary to mention that the main point of vdom was to allow react to offer the API it does performantly but maybe with compiler-based solutions like svelte that isn’t necessary. Lots of people still use react, however.

To my understanding, the virtual DOM used for efficient "diffing" of the subtrees - i.e. producing the optimal set of DOM updates required.

If you are building any abstraction on top of the DOM to handle that, then you have effectively built a virtual DOM.

Or are you suggesting that setting innerHTML and allowing the browser to re-construct the DOM is now faster? I can assure you that is not the case!

Look at their benchmarks. They compare against innerHTML and against (I assume) inserting new DOM nodes. Million is slightly faster than the former, slightly slower than the latter. DOM manipulations are fast these days

Wow, im surprised at how fast that is now - although the benchmarks themselves are doing bulk ops for all the innerHTML stuff, so it will lose some UI state (cursor, etc)

TBH, looking at the benchmark code for partial updates, im not sure I have much faith in the benchmarks overall, but certainly eye-opening regarding the innerHTML performance.

Yeah I was surprised at the numbers too. I'm wondering if those numbers actually imply that reconstructing the Dom from scratch every update is now faster than using a VDom..?

InfernoJS uses a vdom is faster than Svelte in the js framework benchmark.

Even if we set that aside, the differences between something like Svelte and React are still likely to be far less than the differences you'll gain from changing to a more efficient algorithm.

> Then came Google Chrome and their optimizations.

I'd be curious to know whether this holds true for other browsers out there.

Over a certain size, some level of abstraction will usually produce a meaningful reduction in code size in most applications. It's possible for some applications a virtual DOM is the abstraction to achieve that, although I don't think I've seen this in practice. It would require an absolute mountain of "document.createElement() / appendChild() / setAttribute()" code before the lighter syntax of a virtual DOM would net a meaningful size reduction with a modern compressor like Brotli.

Just saying there are probably situations where these might still offer a genuine functional benefit, simply by virtue of offering abstraction.

There are a bunch of replies here focusing on how nice to use virtual DOMs can be, would gently encourage those folk find another industry to ruin.