HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
Matt-Esch
virtual-dom
JavaScript2014–2025
Matt-Esch / virtual-dom

virtual-dom

A Virtual DOM and diffing algorithm

23Distinct people
30Mentions
0Explicit recommenders
11.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A Virtual DOM and diffing algorithm

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year30 dated mentions

Observed mentions: 2014-05-14 06:25:18 UTC to 2025-09-03 11:18:37 UTC.

0510152014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC817
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC14113
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC505
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
virtual-dom A JavaScript DOM model supporting element creation, diff computation and patch operations for efficient re-rendering Motivation Manual DOM manipulation is messy and keeping track of the previous DOM state is hard. A solution to this problem is to write your code as if you were recreating the entire DOM whenever state changes. Of course, if you actually recreated the entire DOM every time your application state changed, your app would be very slow and your input fields would lose focus. virtual-dom is a collection of modules designed to provide a declarative way of representing the DOM for your app. So instead of updating the DOM when your application state changes, you simply create a virtual tree or VTree, which looks like the DOM state that you want. virtual-dom will then figure out how to make the DOM look like this efficiently without recreating all of the DOM nodes. virtual-dom allows you to update a view whenever state changes by creating a full VTree of the view and then patching the DOM efficiently to look exactly as you described it. This results in keeping manual DOM manipulation and previous state tracking out of your application code, promoting clean and maintainable rendering logic for web applications. Example var h = require('virtual-dom/h'); var diff = require('virtual-dom/diff'); var patch = require('virtual-dom/patch'); var createElement = require('virtual-dom/create-element'); // 1: Create a function that declares what the DOM should look like function render(count) { return h('div', { style: { textAlign: 'center', lineHeight: (100 + count) + 'px', border: '1px solid red', width: (100 + count) + 'px', height: (100 + count) + 'px' } }, [String(count)]); } // 2: Initialise the document var count = 0; // We need some app data. Here we just store a count. var tree = render(count); // We need an initial tree var rootNode = createElement(tree); // Create an initial root DOM node ... document.body.appendChild(rootNode); // ... and it should be in the document // 3: Wire up the update logic setInterval(function () { count++; var newTree = render(count); var patches = diff(tree, newTree); rootNode = patch(rootNode, patches); tree = newTree; }, 1000); View on RequireBin Documentation You can find the documentation for the seperate components in their READMEs For create-element.js see the vdom README For diff.js see the vtree README For h.js see the virtual-hyperscript README For patch.js see the vdom README For information about the type signatures of these modules feel free to read the javascript signature definition DOM model virtual-dom exposes a set of objects designed for representing DOM nodes. A "Document Object Model Model" might seem like a strange term, but it is exactly that. It's a native JavaScript tree structure that represents a native DOM node tree. We call this a VTree We can create a VTree using the objects directly in a verbose manner, or we can use the more terse virtual-hyperscript. Example - creating a VTree using the objects directly var VNode = require('virtual-dom/vnode/vnode'); var VText = require('virtual-dom/vnode/vtext'); function render(data) { return new VNode('div', { className: "greeting" }, [ new VText("Hello " + String(data.name)) ]); } module.exports = render; Example - creating a VTree using virtual-hyperscript var h = require('virtual-dom/h'); function render(data) { return h('.greeting', ['Hello ' + data.name]); } module.exports = render; The DOM model is designed to be efficient to create and read from. The reason why we don't just create a real DOM tree is that creating DOM nodes and reading the node properties is an expensive operation which is what we are trying to avoid. Reading some DOM node properties even causes side effects, so recreating the entire DOM structure with real DOM nodes simply isn't suitable for high performance rendering and it is not easy to reason about either. A VTree is designed to be equivalent to an immutable data structure. While it's not actually immutable, you can reuse the nodes in multiple places and the functions we have exposed that take VTrees as arguments never mutate the trees. We could freeze the objects in the model but don't for efficiency. (The benefits of an immutable-equivalent data structure will be documented in vtree or blog post at some point) Element creation createElement(tree:VTree) -> DOMNode Given that we have created a VTree, we need some way to translate this into a real DOM tree of some sort. This is provided by create-element.js. When rendering for the first time we would pass a complete VTree to create-element function to create the equivalent DOM node. Diff computation diff(previous:VTree, current:VTree) -> PatchObject The primary motivation behind virtual-dom is to allow us to write code independent of previous state. So when our application state changes we will generate a new VTree. The diff function creates a set of DOM patches that, based on the difference between the previous VTree and the current VTree, will update the previous DOM tree to match the new VTree. Patch operations patch(rootNode:DOMNode, patches:PatchObject) -> DOMNode newRootNode Once we have computed the set of patches required to apply to the DOM, we need a function that can apply those patches. This is provided by the patch function. Given a DOM root node and a set of DOM patches, the patch function will update the DOM. After applying the patches to the DOM, the DOM should look like the new VTree. Original motivation virtual-dom is heavily inspired by the inner workings of React by facebook. This project originated as a gist of ideas, which we have linked to provide some background context. Tools html2hscript - Parse HTML into hyperscript html2hscript.herokuapp.com - Online Tool that converts html snippets t
Read the full README on GitHub

What Hacker News says

30 sources
"Frontend" is literally the integration of Web Platform APIs. So you need (1) the knowledge of what platform APIs exist (2) the ability to reason about existing abstractions (3) the ability to define abstractions. In modern life all three are considered unsafe things. Therefore to prevent people from entering invalid states exists The Framework: useless abstraction layer that does nothing besides be conventional. That's a common enough pattern anywhere population's above Dunbar; whether it's embodied by React or TypeScript or Windows or an entirely different order of lowest-common-denominator monoculture is immaterial. Thankfully, software maintains an objective material component - the code, which they're trying to now turn into another wishy-washy thing you interact with using endless imprecise human language. Purely in terms of that, i
Read the rest
t remains possible to propose some ways to get a project off the ground more efficiently by virtue of dodging the toxic mainstream: TL;DR conventional: native DOM manipulation; state management with Observable; Vite; TDD. TL;DR forward-thinking: same but in proper static language: write in Rust, compile to WASM. TL;DR exotic: ClojureScript or another Lispy language that compiles to JS or WASM. Ofc, unless totally cowboying it, you also gotta be able to counteract the illusion of social proof. Ideally you want to be actively shaming people for building and normalizing bloatware. Preferably packing 1-2 yesmen worth of social proof of your own, just to get basic parity with the "best practices" in close quarters. As always, depends on what you're building, for what purpose, and, critically, with whom... fuck all that though, the objectively bestest solution is always https://github.com/Matt-Esch/virtual-dom /s That repo is a milestone of where history took its next wrong turn. I remember it making some waves when it dropped, and it's certainly the first VDOM implementation I saw. I considered it a good, original idea. IIRC, React came around about that time: to take the simple and sane "VDOM" optimization, apply it judiciously (i.e. where it doesn't), and make it possible to bolt enough shit onto it (redux! teaching you to type the same thing thrice before typescript! SAGA! that one weird DB paper from '74 applied to frontends JS' half-baked half-async "generators", just to demonstrate to people that they should revere the old CS publications, and definitely not anything like read them or reason about them!) Just so that people could hold bloody bootcamps about it, where they'd be able to weed out any junes capable of reading MDN for themselves. ("Bootcamp" is another cosmic joke like "Instagram" and "Trump". That thing where they harass people into obedience then turn them into socially sanctioned murderers? Ok checks out, let's name our programming learning experience! It's nothing if not profoundly mission-driven!) Back in those days or a little later, I remember Vue 1 and 2 being pretty great: it somehow managed to do its thing without first having to introduce three whole new dialects of JavaScript and counting. Overall I'm glad to be out of the frontend space for a good while now and only learning about it from the confused screaming of those still trapped there. (Oh and also Next's "static build" is a Docker container I had to cook up myself, which is a next level of ridiculous; as with VDOM, you first need to have seen the past level in order to recognize it as regress, and I presume a lot of people simply haven't had the opportunity to pursue any form of informed comparison) (For "agentic workflows" idk -- just don't use them ffs the externalities are not remotely priced in; otherwise you'd be the exact same problem as them -- the designed-by-corporate-committee frontend DX of the past decade certainly strike me as something that'd make more sense to a statistical model than to a human mind.)
In Next.js is infuriating
I would try to think of it from a first-principles approach. You can begin with a blank slate, for instance, a single HTML file with a <script> tag. Only when "doing it yourself" becomes tedious do you start to look for libraries to solve your problem. Personally, I find a bare minimum of tooling to be valuable. I have built SPAs using 100% vanilla JS, and it can be quite repetitive and error-prone. I'd recommend using highly simple build tooling (maybe Brunch) and an extremely simple view layer like https://github.com/Matt-Esch/virtual-dom. Pretty much everything else you can build yourself with surprisingly few lines of code -- state management, routing, event handling, data bindings, etc. I think of it as "building your own framework", and although you might not want to do it for every project, the learning experience is great.
In Ask HN: Resources for catching up on modern JavaScript for Python/C++ Programmer
There is hyperscript which is a bit more "mature": https://github.com/dominictarr/hyperscript#example There is virtual-hyperscript which ports the above to virtual-dom: https://github.com/Matt-Esch/virtual-dom/tree/master/virtual... I made a similar-ish "library" about an year ago: https://gist.github.com/awalGarg/8a0e18c6fe87456d885f And there are all sorts of similar DSLs you can find on npm/github for JS. In a bit less time, you can write your own. In even lesser time, you can just do what you used to do prior to all this. This does however seem like a pretty popular idea in the JS community which keeps getting "discovered" every now and then.
In RE:DOM – Tiny DOM library
It's perhaps not as custom as I made it sound. The code we have is a wrapper around the [virtual-dom](https://github.com/Matt-Esch/virtual-dom) library which does most of the low level work. The "widget" framework is a series of simple ES6 classes that allow us to keep state around and delegate events as actions up to Ember controllers. We had a lot of pre-existing, battle tested code that was written using Ember idioms and was not a performance problem, so we kept that around and used the virtual dom stuff just for rendering HTML as fast as possible. Why not React? Our main pain point was rendering, and we didn't need all the extra stuff React provided as those bases were already covered by Ember. Why include 26k min+gzip when we would only use a small part of it that was already provided by another excellent virtual-dom library?
In We finally did something about [Ember on] Android Performance
I am hesitant to spend time learning on react because of this: " SomeCallMeTim: I have been learning new technologies pretty much continuously. It's not impossible, especially if you follow sites like Hacker News, to keep a finger on the direction of the industry, and then try to stay on top of the next new hot technology of the year. But I hear you on the "worse" technology sometimes winning. You mentioned Java; it was worse than just about all other major contenders, and is only finally losing popularity. On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that wil
Read the rest
l prevent you from migrating your code to the next web standard! Much better. And how many app teams have 100 or more active developers? Probably fewer than a dozen, and I submit that none of them probably should. Certainly not the Facebook app: It has a lot of features, but not that many features, and yet it has a 150Mb footprint. When I hear things like that, I can't help but fill in "junior" or "mediocre" in front of "developers." React helps to prevent people from breaking each others' code when you have bloated development teams filled with junior developers. React has some cool ideas, but all told I think it's a step backward for software engineering, and certainly isn't as much of a help for small teams, especially if you want to have a CSS/SCSS/LESS expert styling your product without having to dig through JSX files, for instance. The Java rationale was similar, IMO: You can use the Java abstractions to allow lots of mediocre developers to make contributions to a product without breaking each others' code. At least not as frequently as when they can poke right into random data structures and change things arbitrarily. If it weren't for Google's decision to require Java for Android, I think Java would be relegated to big company web backend development. I do like React's idea of the Virtual DOM for optimization, but you can get that without using React. [2] React Native is great for using native components and driving them from JavaScript, but it's also not the only game in town. [3] Back to the original point, though: You can stay on top of the Hot New Technologies, but when there are good technical reasons to use alternate technologies, stay on top of those as well. And then explain clearly to your clients (or employers) why the current fad is a fad, and how to get the key benefits of that stack without its drawbacks. Oh, and choose clients (or employers) who will listen to strong technical arguments. :) [1] https://www.pandastrike.com/posts/20150311-react-bad-idea [2] https://github.com/Matt-Esch/virtual-dom [3] https://www.nativescript.org/ "
In React vs. Angular 2
I have been learning new technologies pretty much continuously. It's not impossible, especially if you follow sites like Hacker News, to keep a finger on the direction of the industry, and then try to stay on top of the next new hot technology of the year. But I hear you on the "worse" technology sometimes winning. You mentioned Java; it was worse than just about all other major contenders, and is only finally losing popularity. On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices. [1] Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app. Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better. An
Read the rest
d how many app teams have 100 or more active developers? Probably fewer than a dozen, and I submit that none of them probably should. Certainly not the Facebook app: It has a lot of features, but not that many features, and yet it has a 150Mb footprint. When I hear things like that, I can't help but fill in "junior" or "mediocre" in front of "developers." React helps to prevent people from breaking each others' code when you have bloated development teams filled with junior developers. React has some cool ideas, but all told I think it's a step backward for software engineering, and certainly isn't as much of a help for small teams, especially if you want to have a CSS/SCSS/LESS expert styling your product without having to dig through JSX files, for instance. The Java rationale was similar, IMO: You can use the Java abstractions to allow lots of mediocre developers to make contributions to a product without breaking each others' code. At least not as frequently as when they can poke right into random data structures and change things arbitrarily. If it weren't for Google's decision to require Java for Android, I think Java would be relegated to big company web backend development. I do like React's idea of the Virtual DOM for optimization, but you can get that without using React. [2] React Native is great for using native components and driving them from JavaScript, but it's also not the only game in town. [3] Back to the original point, though: You can stay on top of the Hot New Technologies, but when there are good technical reasons to use alternate technologies, stay on top of those as well. And then explain clearly to your clients (or employers) why the current fad is a fad, and how to get the key benefits of that stack without its drawbacks. Oh, and choose clients (or employers) who will listen to strong technical arguments. :) [1] https://www.pandastrike.com/posts/20150311-react-bad-idea [2] https://github.com/Matt-Esch/virtual-dom [3] https://www.nativescript.org/
In What is a coder's worst nightmare? (2014)
> I haven't seen a mechanism a nice in elm like the virtual dom. It's not quite clear what you mean, the "view" function of a standard Elm application is a virtual dom, elm.html is implemented on top of the virtual-dom library[0]. If you mean component, as far as I understand in Elm you'd use separate models and sub-functions in separate modules for each concern ("component")[1]. Elm subscribes to the "single point of truth" philosophy[2] so there isn't really a sense of component-local state or lifecycle. [0] https://github.com/Matt-Esch/virtual-dom [1] https://gist.github.com/evancz/2b2ba366cae1887fe621#nesting [2] like Om except more so
In Optimistic UI and Reactive Programming with Elm
Why not just have MVC for the page, and MVC for components? Each component would render itself. I personally think that this requires a lot of machinery under the hood, such as caching and batching requests (since no one knows ahead of time what components will need to be rendered). At least that's what we built in our Qbix Platform (http://platform.qbix.com). Reusable components you just place on a page and they "just work". Unlike React, etc. they support more than just re-rendering. You can of course have a virtual DOM (via a lib like Mithril or https://github.com/Matt-Esch/virtual-dom etc.) but it would be nice to handle other kinds of events besides just "re-rendering".
In What Comes After MVC

Showing the 15 most recent of 30 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.