4 ms·
Virtual DOM approaches never really were about performance. They are about being able to write idempotent render functions in declarative style so that you don'
by ShellfishMeme 11y ago
Virtual DOM approaches never really were about performance. They are about being able to write idempotent render functions in declarative style so that you don't need to deal with massive amounts of DOM state management.
In the end you want to write a function that just expresses what the state of the DOM should be depending on the input parameters and have something deal with applying those changes to a very stateful API. If the application state changes, all you want to do is say 'things have changed somehow, just re-render this component'.
This was possible before with classic templating, but it wasn't very efficient and had problems when dealing with re-rendering interactive elements. You would lose focus on input fields for example, and had to use some post-render hooks to fix the state of the DOM up afterwards.
Using virtual DOM structures fixed this problem in an elegant way and allowed rendering to the DOM to be integrated into more functional programming styles, which made more reactive architectures possible.
It all boils down to humans not being good with reasoning about state changes over time and how to express those imperatively. The only solution to that is not to do it and go more functional.
This is also why I am not a big fan of things like incremental-dom. It ignores the whole idea why we wanted declarative DOM handling in the first place and replaces it with a very imperative and side-effect heavy API. In that case, just use the DOM directly.
- ivank 11y ago> This is also why I am not a big fan of things like incremental-dom. It ignores the whole idea why we wanted declarative DOM handling in the first place and replaces it with a very imperative and side-effect heavy API. In that case, just use the DOM directly. incremental-dom still solves the declarative DOM problem. You express exactly what DOM you want in a template that compiles to incremental-dom calls. It's just a more efficient way to do what React does, skipping the intermediate representation. Why does it matter if the incremental-dom calls have side effects, if the end result (of an updated DOM) is the same? If you use the DOM directly as you suggest, you end up writing a lot of manual state transitions, and probably bugs from not covering and testing absolutely every transition. incremental-dom doesn't have that problem because it's updating the whole tree for you, just like React.
- ShellfishMeme 11y agoBecause I have no return values to hold on to. Everything in the render function is a side effect. There's no way to collect the intermediate dom representation in data structures and combine it together later. There is no room for asynchronicity from what I have seen. What if I'd like to combine some reactive streams to send me the desired dom structure as state changes over time, piece them together and send them to the renderer?
- ivank 11y agoTrue, you don't have asynchronous template rendering, but you can still asynchronously collect data into your own data structures, then keep re-rendering the whole thing with an incremental-dom render function.
- localvoid 11y ago>Virtual DOM approaches never really were about performance. "React abstracts away the DOM from you, giving a simpler programming model and better performance" https://github.com/facebook/react https://github.com/facebook/react It seems strange to me that many developers are now trying to convince everyone that vdom wasn't selling as a way to get better performance. Yes, getting rid of data changes over time is important property of vdom approaches, but when all this vdom hype were started, everyone is also talked how awesome it is in terms of performance.