Virtual DOM is pure overhead (2018)

You are considering this from the side of one web app, but users generally will have dozens of tabs open. When you need a Core i7 with 16GB of RAM to handle your browser, because each developer didn't care about their individual performance, the web experience becomes a nightmare.

I read this long ago and I love Rich Harris and I think he is a super smart guy. But the problem as I see it is that he focuses on VDOM as just a performance hedge. As browsers improve (or rather as the market consolidates on WebKit variants as is happening now), then certain DOM operations that took substantially longer on average on IE or Edge vs. Chrome will no longer be as much of a problem, which is my view of what the VDOM was trying to solve. There are some operations that depending on the browser and how the internal mechanics of the layout engine work will take substantially longer on one browser vs another for instance. You are at the mercy of each layout engine's architecture. In this case, if you use a VDOM to calculate the simplest operation to be performed and just push the end results with the simplest operations manageable, you can elide away the differences between certain DOM operations taking longer than others across browsers. Setting innerHTML for example on IE (Trident), Edge (EdgeHTML), Safari (non-Blink WebKit), Firefox (Gecko) and Chrome/Chromium (Blink) is likely the best way to ensure consistent performance since it is one of the base operations you will need to do to manipulate HTML.

I personally love the idea of the VDOM, because it liberates the content from being stuck to one document type: HyperText. While true when VDOM showed up on the scene, Facebook and others said the VDOM would help cure performance issues and that was the main selling point.. as we see now with things like ReactPixi, and Netflix using React for some of their apps - the VDOM is infinitely valuable for transcending the limits of HyperText and instead abstracting it away so that content may be projected by any sort of renderer using the same scaffolding as web pages. If you code to just the DOM - that is is where you will stay. Forever.

> this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman”

The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.

I need to sit down and write a long blog post on this subject, but the tl;dr would be "The modern Web environment, from programming to browsing, is a massive case of path dependence; if we were starting from scratch today, knowing all that we now know, we would not design anything like this."

I have in my head a few dozen examples of what I mean, some small and some large. I won't even get into TCP/UDP which has already been argued over a thousand times. But I would point to RINA and other paradigms of remote execution:

https://en.wikipedia.org/wiki/Recursive_Internetwork_Archite...

But that's the large scale stuff. We can also focus on very minor stuff where a different design decision might have lead to less trouble. Take, for instance, a mouseclick. Which element on a Web page should receive that mouseclick? Well, there is a well-established hierarchy that the browsers respect, walking up the DOM, checking each element to see if it has a handler registered. It can be a royal pain if your application needs you to break out of that hierarchy, and you can end up with something buggy because this is still an area where the different browsers have slight differences. But why should any hierarchy exist by default? We could have it such that there is no hierarchy by default, the only hierarchy is that which is defined by me, the programmer. I believe this original decision (of a default hierarchy) was made because there was an assumption, in the 1990s, that each page would be hand-coded, but nowadays we have frameworks that write much of our Javascript for us, so the possibility of assigning mouseclick handlers on the basis of classes, rather than the DOM, seems like a smart choice now, but probably didn't in the 1990s.

I tried to write about some of this in essays like "The problem with HTML":

http://www.smashcompany.com/technology/the-problem-with-html

and also, "HTML is the failed GUI for TCP/IP":

http://www.smashcompany.com/technology/html-is-the-failed-gu...

I'm not sure I really communicated myself very well previously, but perhaps if I focus on it, I can build the case that we've been following a path into a dark wood, and we've been so busy focusing on the path one step before us that we have perhaps not noticed that we've wandered into the lands where, in innocent days of yore, developers would have warned, "There be dragons, do not go."

Have a look at Astro. It's compiled to static by default and then parts that need to be dynamic are hydrated at runtime.