This idea of creating DOM with some API is not new and never really understood it. Just look at the login class, it's way more complex than plain HTML, hard to read and messes with .this.
If you want DOM in your code, JSX is the way to go.
With more complex project there’s benefits of having purely updatable components, the support of just native JS without quirks and knowing exactly what’s happening and when without black magic.
But if course it always depends on the project which way is better.
With more complex projects, anything that isn't a declarative becomes painful to manage. In complex web-apps, the benefits of using a VDOM over imperative libraries like this far outweigh the extra O(N) memory consumption.
> this far outweigh the extra O(N) memory consumption.
Calculating memory overhead for vdom is actually pretty hard. With imperative code there will be several different code paths for initial rendering, updates and removal, and depending on the ratio of component instances per component type in the application, vdom can consume less memory because there will be less code and less code means that there will be less internal data for JIT.
Also, if it is a highly dynamic application with high ratio of dynamic bindings per DOM element, and imperative library will wire all dependencies with direct DOM bindings in a huge dependency graph, it is much more likely that this graph will consume more memory, especially in use cases like filtering large lists.
Two days ago I started an HTML application. One day ago I realized, I'd want to add localization to it. Today I realized, that I may be better off to have the whole document be created dynamically, since I can then easily implement localization. Note, this is an "app" not a "doc".
If you want DOM in your code, JSX is the way to go.