6 ms·

Virtual DOM is not a feature

14 points by tdurden 11y ago

jhall1468 11y ago
> Does this difference in semantics matter? Probably not. Even React's own documentation gets it wrong. First of all, if you are arguing that they're different things then it isn't a argument in semantics. Secondly, the docs don't get it wrong. Conceptually it presses the refresh button... there not saying it literally presses the refresh button. That said, I liked the example of making it slow. Perhaps it's just my mind playing tricks on me but the button counter felt slower when clicking it rapidly. Pretty amazing that such a bare-bones example "felt" different.
mercurial 11y ago
My problem with this article (apart from the title of the submission) is that the author's point is, IMHO, not very well thought out. It's not a question of "using the virtual DOM or not", it's a question of "use immediate rendering" (what the author attempts) or "use a diff-and-patch algorithm" (what React does).
ludamad 11y ago
Why the more strongly worded title?
- cjhveal 11y ago
  Yeah, I think the new title misses the point of the article, and is frankly click-bait.
- mercurial 11y ago
  It's not "more strongly worded", it's plain misleading, as reading the first paragraph reveals: > I tried to build the slow version, and learned that Virtual DOM is not an optimization, but rather a foundational building block for declarative UIs on the web.
- joshkpeterson 11y ago
  +1 should be changed or deleted
- tdurden 11y ago
  The title in the article changed after submission. https://github.com/uniphil/uniphil.github.io/commit/230de9cf6a1e41cabb8b9406446eb0c424034cd8#diff-8018522fe7d646a82658459f346f8029 https://github.com/uniphil/uniphil.github.io/commit/230de9cf...
lopatin 11y ago
I think the beginning of this article is spot on. A declarative UI library for the web needs to have something like virtual DOM so that the actual DOM is strategically updated when a higher level component updates. No DOM state like input focusing is lost. The part that I don't understand is when the author mentions that the "nifty algorithms that operate on the Virtual DOM" are the key to React's speed. It was my understanding that 1: There are no algorithms that operate on the virtual dom. It is blindly updated every time a component update happens. And 2: That the algorithms that compare the virtual dom and the real dom are the essence of the "Virtual DOM" idea. In this sense, React is no different from the other declarative UI frameworks out there and this is where the point of the article was lost to me.

14 points by tdurden 11y ago

> Does this difference in semantics matter? Probably not. Even React's own documentation gets it wrong. First of all, if you are arguing that they're different things then it isn't a argument in semantics. Secondly, the docs don't get it wrong. Conceptually it presses the refresh button... there not saying it literally presses the refresh button. That said, I liked the example of making it slow. Perhaps it's just my mind playing tricks on me but the button counter felt slower when clicking it rapidly. Pretty amazing that such a bare-bones example "felt" different.

mercurial 11y ago

My problem with this article (apart from the title of the submission) is that the author's point is, IMHO, not very well thought out. It's not a question of "using the virtual DOM or not", it's a question of "use immediate rendering" (what the author attempts) or "use a diff-and-patch algorithm" (what React does).

ludamad 11y ago

Why the more strongly worded title?

cjhveal 11y ago
Yeah, I think the new title misses the point of the article, and is frankly click-bait.
mercurial 11y ago
It's not "more strongly worded", it's plain misleading, as reading the first paragraph reveals: > I tried to build the slow version, and learned that Virtual DOM is not an optimization, but rather a foundational building block for declarative UIs on the web.
joshkpeterson 11y ago
+1 should be changed or deleted
tdurden 11y ago
The title in the article changed after submission. https://github.com/uniphil/uniphil.github.io/commit/230de9cf6a1e41cabb8b9406446eb0c424034cd8#diff-8018522fe7d646a82658459f346f8029 https://github.com/uniphil/uniphil.github.io/commit/230de9cf...

lopatin 11y ago

I think the beginning of this article is spot on. A declarative UI library for the web needs to have something like virtual DOM so that the actual DOM is strategically updated when a higher level component updates. No DOM state like input focusing is lost. The part that I don't understand is when the author mentions that the "nifty algorithms that operate on the Virtual DOM" are the key to React's speed. It was my understanding that 1: There are no algorithms that operate on the virtual dom. It is blindly updated every time a component update happens. And 2: That the algorithms that compare the virtual dom and the real dom are the essence of the "Virtual DOM" idea. In this sense, React is no different from the other declarative UI frameworks out there and this is where the point of the article was lost to me.