Ist das Virtual DOM tatsächlich schnell? Was bringt es dir wirklich?

Roh gesehen nicht, ein handgeschriebenes, gezieltes DOM-Update schlägt das Diffen eines Baums immer. Was das Virtual DOM dir bringt, ist ein Programmiermodell, in dem die UI eine Funktion des States ist, dazu Batching, sodass viele Updates in einem Commit landen, und ein austauschbares Render-Target. Es ist schnell genug für fast alles und räumt eine ganze Klasse manueller DOM-Buchhaltungsbugs weg.

Ehrlich gesagt nein. Wenn du die DOM-Mutation von Hand schreibst, gewinnst du jedes Mal, weil React erst einen Element-Baum bauen und ablaufen muss, bevor es irgendetwas anfasst. Was du dafür bekommst, ist ein Modell, in dem ich beschreibe, wie die UI für einen bestimmten State aussehen soll, und die Übergänge zwischen Zuständen nie von Hand verwalte, denn genau da wohnten früher die Bugs. Dazu kommt Batching, fünf setState-Aufrufe in einem Handler sind ein Commit, und ein Render-Target, das nicht an den Browser gebunden ist. Die Kosten sind aber real. React führt eine Komponente und alles darunter erneut aus, wenn es nichts stoppt, und deshalb verbringen wir Zeit mit Memoization. Signalbasierte Frameworks umgehen das, indem sie Abhängigkeiten auf Wertebene tracken, sodass nur exakt der Textknoten aktualisiert wird, der sich geändert hat, und bei reinem Durchsatz gewinnen sie. React hat den Abstand mit Concurrent Rendering verkleinert und jetzt mit dem Compiler, der Memoization automatisch übernimmt, was den größten Teil der manuellen Arbeit entfernt, die früher die Steuer war.