Again, why is the scary second half of that sentence an absolute certainty or bad? There's no law requiring use of innerHTML, and it's been easy to beat React on raw performance in many cases (to their credit, that's been getting harder but that's always a challenge for a general purpose library) — and in most cases none of that matters because you're not triggering updates fast enough to care. Ease of use and all of the other concerns are far more important for most people.
Similarly, if people are building reusable components it's not clear why using different virtualdom libraries or not using one at all is a problem. Doesn't sound software engineering practice recommend a well-defined public interface rather than deeply interconnecting them like that? Besides, this is the web: what are the odds that you wouldn't quickly hit a problem where component X depends on v1.2.3 but component Y requires v2.3.4?
> it's either careless or dishonest to compare the two without acknowledging the possibility of using a helper function or two to simplify the second one, as JavaScript developers have been doing routinely for multiple decades.
To quote from the article:
--- start quote ---
DOM APIs are horrible, cumbersome, awkward and clunky. Polymer and others are bravely trying to use DOM APIs only, but even they resort to innerHTML anywhere they don’t have to put on a show (tests, for example). When Web Components take root, the web will be flooded with less performant innerHTMLs and possibly re-implementations of snabbdoms and virtual-doms (obviously incompatible)
--- end quote ---