How do frameworks update the DOM without a virtual DOM?

I have been researching React’s virtual DOM (how it works) for a while now, and so far I have understood the following:

It has an in-memory DOM representation at all times

When something changes in the application/component, the virtual DOM creates another representation of component’s/application’s DOM - this time how it should look like

It “diffs” them to find the minimum differences that need to be updated in the real DOM

It updates the real DOM

I wanted to know if other frameworks update DOM and detect changes differently and if they do - how?

2 Likes

It’s all Javascript.

JS is attached to “events” that are exposed by the browser API. The browser can notify JS on anything from clicks to hovers to scrolling and even that the user resized the browser window or pressed a key on the keyboard.

When JS is attached to these events, it can fire functions to do something when it happens. JS can also manipulate the DOM in any way imaginable. It can add and remove HTML elements, change their attributes, inner content, or store custom data.

The end result is exactly the same, it’s Javascript that is monitoring and updating HTML elements. Managing a virtual DOM is just a technique but not a requirement.

In summary, the browser exposes “events”, and Javascript can “listen” for the events and act on them.

The main problem with adjusting the DOM in real time is if the user refreshes the page, or clicks the back button, or wants to bookmark the current state of the page. A virtual DOM can allow the app to save “state” or basically be able to bring the user back to the same place even if they refresh the browser. This is not as easy if the app isn’t storing the entire DOM at once.

One last thing that typically happens is Javascript will be used to manipulate the browser’s history so that the app can take people to different states. For example if you build a page where JS alone changes the main content, you will need a way for users to bookmark which page they are on, or to use browser back/forward buttons.

I believe that OP was asking how frameworks such as Angular 2, Vue, or Ember handle rendering and interaction with the DOM. I believe that none of them manipulate the DOM directly until necessary, as you’re suggesting, nor do I think your understanding of React’s Virtual DOM is correct (routing has nothing to do with the Virtual DOM).

But I don’t have enough knowledge about other frameworks to answer OP’s question in a satisfactory way.

I was generalizing how it works.
There are many techniques for how to handle DOM changes.
I didn’t say routing has to do with virtual DOM, I said routing is something important to deal with when updating the DOM in real time, so users can bookmark certain page conditions.

In Vue, for example, they have models which are just JS objects. If the object is updated/changed, then Vue changes the DOM to match. It’s not really a “virtual DOM” in that case, it’s just Vue looks for changes to object models and then updates the views when the models change. There are many nuances to how it works, of course.

Vue.js 2.0 does use a virtual DOM: https://medium.com/js-dojo/whats-new-in-vue-js-2-0-virtual-dom-dc4b5b827f40

1 Like

They also talk about Vue’s object model here: https://vuejs.org/v2/guide/reactivity.html

Somehow I think what React means by “virtual DOM” is likely not the exact same thing as Vue means by it. Or maybe it’s the exact same technique used by both?

Have a look at the first diagram on that page, it even mentions the Virtual DOM Tree! Also, check out this page where they compare Vue directly with React:

React and Vue share many similarities. They both:

  • utilize a virtual DOM
  • provide reactive and composable view components
  • maintain focus in the core library, with concerns such as routing and global state management handled by companion libraries

I think you’re getting confused with the differences between when and what they decide to rerender. Quoting from lower down the same page:

In React, when a component’s state changes, it triggers the re-render of the entire component sub-tree, starting at that component as root.

and

In Vue, a component’s dependencies are automatically tracked during its render, so the system knows precisely which components actually need to re-render when state changes.

2 Likes

That doesn’t explain virtual DOM.

The OP mentioned react does a before/after compare to DIFF copies of the DOM and only updates the differences.
Maybe that’s not accurate either.

The OP makes it sound like React compares different virtual DOM versions and updates based on the differences. While Vue makes it sound like they specifically monitor model objects and update the view when the model properties change.

Those do sound like quite different techniques to me.

That’s what a virtual DOM does… and it works that way in both React and Vue. With a vdom, you have to decide what you want the DOM to look like, and you pass a representation of that state to the vdom, which compares it to an in-memory representation of the existing DOM state and then calculates what has changed and the best way to modify the real DOM with those changes.

What you’re talking about is the process by which the framework determines that some piece of state has changed and triggers components to re-render - the output of the components is then passed to the vdom implementation to apply to the actual DOM. This is exactly what is shown on this diagram:

2 Likes

So the question remains then, is there some other framework that implements reactive pages without a virtual DOM system? Maybe that’s the question the OP is asking? I don’t feel like looking up Ember and Angular and Meteor and all these others at the moment. Perhaps vdom is the only way to fly at this point in time.

Maybe that’s the question the OP is asking?

Yes. OP asked how other frameworks handle this. I believe they understood what the Virtual DOM is.

1 Like

Other frameworks that do not use a virtual dom would do it in the traditional JavaScript way. My approach in my personal framework is that I can request to the server a specific HTML fragment or component via an AJAX call within the page. Then the appropriate content will get appended to a given container or will replace the old content and get initialised accordingly. Personally I’m still not sold on the virtual dom. I think if it ever becomes a really worthwhile advantage it would get implemented natively by the browsers. Even though it is claimed to be a faster approach there does seem to be a tradeoff in CPU usage off which mobiles are clearly at the loosing end.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.