I have huge respect for Douglas and what he’s done for the Web, but this is a bit tone deaf to developer needs. No, you should *probably* not build a medium or larger web app today by “just” using the DOM directly or with thin abstractions like the one he proposes. Either you will wind up with a tightly coupled mess of a codebase or you will re-invent a lot of the concepts libraries and frameworks have spent years perfecting. The primary hurdle with using the DOM directly is not node creation (that indeed only needs a pretty thin abstraction to become palatable), it’s handling model updates. There are two avenues for updating the UI when using the DOM directly: 1. You naively overwrite the entire subtree that encompasses the nodes you actually need to update. Lots of problems with this: loss of user state, performance, tight couplings. 2. You use targeted DOM methods to update the specific attributes, text nodes, and properties you need. This is less destructive and generally faster, but it has several downsides. First, it also requires tight couplings across the entire codebase. Second, small increases in use case complexity require large increases in code complexity and size (even something as simple as two different controls that need to change different parts of the same attribute is nontrivial). The whole point of React, Lit, and many other libraries was to combine the DX of (1) with the performance of (2). Other frameworks like Vue use reactivity to improve on the DX of both. The raw DOM is fine for content-heavy sites that only need very little DOM update code. Even if they are large content-heavy sites. But web apps are a different story. I WANT a future in which frameworks and libraries are not as necessary for building nontrivial web apps. But to get there, we need a higher abstraction over the DOM, not to gaslight developers that they’re doing it wrong.