I think you misunderstood the point of SSR too. One of the main reasons why people want SSR is for better SEO. Since it is well known that search engines like Google's will only execute synchronous Javascript when crawling pages, the search engines could miss the content loaded from ajax and worsen the SEO. This is the main reason why we want SEO. Anyways, nobody is trying to force you to use Virtual DOM and you are free to develop your app anyway you wish. If you think your way is better, prove it to people. To me, the only valid point you have made so far is how directly doing DOM manipulation is faster, which is obvious and trivial. I won't agree that the "equivalent" imperative version of the app you wrote is simpler, and it is obvious to me that it is much harder to scale and maintain. I feel that your arguments to Virtual DOM has been like: "Using integration to find the area under the curve is stupid when we can just draw the curve to measure the area manually." or "Higher order functions is absolutely making things overly complicated while we can just define the function directly." You just don't seem to be able to appreciate any level of abstraction and prefer doing things in a low-level way. Perhaps you should consider writing your future webapps directly in webassembly because the interpreter behind javascript is so complicatedly written. LOL

Side notes on JSX, I am not a big fan of writing HTML inside Javascript. I prefer the Vue single file component way of doing virtual DOM. See more here .

Thanks for typing all this. I really appreciate it. I hope this could help you understanding why Virtual DOM has become such a big thing in the frontend world. Please read the following with an open mind. :) I think you misunderstood the advantages of a Virtual DOM. Virtual DOM was not intended to speed things up. So your claim about "direct DOM manipulation is faster" is correct. Direct DOM manipulation is obviously faster and more efficient if (or even if not) written correctly. However, I think you totally neglected the two main benefits that Virtual DOM provides. Decoupling the real DOM from the application. Allowing application to be rendered in a different environment; e.g. server-side rendering. Enabling developers to write their application declaratively instead of imperatively. Extending from the second point, writing your application declaratively basically means that you can write your application as if the whole page is going to be re-rendered on each change; while the diffing algorithm will figure out the "minimal" changes to apply to the real DOM. This makes the application much easier to reason about because we can think of our application simply as a function state => UI . In another words, we can easily figure out how the application looks like at any given state. In contrast, manipulating the DOM here and there makes the UI a lot harder to reason about. Developers would need keep an "image" of the application in their mind in order to work on it. Using your code as an example: var count = 0 , appDIV = make( 'div' , d.body, { id : 'app' }, 'The current count is ' ), countText= node_add(appDIV, count), cloneIMG = make( 'img' , false , { src : 'https://media.giphy.com/media/cuPm4p4pClZVC/giphy.gif' }); function updateApp ( ) { var newCount = Math .floor( Math .random() * 10 ); if (newCount < count) { node_stripEnd(appDIV, count - newCount); count = newCount; } else while (count < newCount) { count++; node_add(appDIV, cloneIMG.cloneNode()); } countText.data = count; } It is not immediately obvious how the count relates to the UI of the app until you look into how updateApp works; whereas virtual DOM allow us to define our app like this: const createVApp = count => createElement( 'div' , { attrs: { id: 'app' , dataCount: count, // we use the count here }, children: [ 'The current count is: ' , String(count), // and here ... Array .from({ length: count }, () => createElement( 'img' , { attrs: { src: 'https://media.giphy.com/media/cuPm4p4pClZVC/giphy.gif' , }, })), ], }); By building your app UI in an declarative way, it is immediately obvious how the count will affect the DOM if you are highly comfortable with the createElement function. Most people however would not feel comfortable reading createElement . This is why React decided to use JSX, the above createVApp function could be written into something like: const createVApp = count => (<div id= "app" dataCount={count}> The current count is {count} {Array.from({ length: count }, () => (<img src= "https://media.giphy.com/media/cuPm4p4pClZVC/giphy.gif" >))} </div>); This makes things much easier to read. You can see how JSX compiles to createElement with babel here . The syntax of the React's createElement is slightly different, but you get the idea. I hope this will change your mind about the Virtual DOM. It is undeniable that it is less efficient than direct DOM manipulation. By giving up a little bit on performance, we gain the ease of development and maintenance, which in the long run wins!

Thanks. I did eliminate the explicit creation of the Promise, didn't I? I don't prefer the ternary operator tho as it is not as readable as a guard clause.

I am surprised no body mentioned Jest. Jest is probably the most complete framework that you can find out there. Comes with doms which is great for front-end. Comes with spies and mocks which is essential for unit testing. Comes with code coverage which is awesome.