Re:RE:DOM – Tiny turboboosted JavaScript library for creatin...
by anonytrary on Sunday January 20, 2019 @02:31PM
(#18955053)
> manipulating DOM objects without tricky state machine ... was always faster than with it.
You miss the point of VDOMs. VDOMs aren't so much about performance as they are about ease of development and automatically maintaining tree consistency. No one disputes the fact that creating templates and diffing them against the DOM adds overhead compared to writing out the equivalent instructions manually. The point is that nobody wants to write out imperative spaghetti for complex applications.
Re:RE:DOM – Tiny turboboosted JavaScript library for creatin...
by baybal2 on Sunday January 20, 2019 @03:30PM
(#18955403)
> The point is that nobody wants to write out imperative spaghetti for complex applications.
You really don't have to, you just have to walk out of that "wood of popular notions." There are libs to handle functionality of any part of a modern MVC app: reactivity, input handling, declarative components, templating... that don't even making you think of manually manipulating the DOM tree.
Even in the often brought forward case "when a lot of changes to DOM don't translate to changes in markup," like demonically complex template merges, never seen in real life, that VDOM proponents like to throw into benchmarks, VDOM often lost because they were trying to do browser's job when they really shouldn't.
Browsers already used a lot of very similar logic on the inside when DOM 3.0 was being popularised, and it's only natural that VDOM was losing out by trying redoing what browsers were already doing.