4 ms·
What a strange post. Yes, virtual DOM is overhead, much like JIT compilation is an "overhead". But this overhead ultimately translates to better performance bec
by computerex 7y ago
What a strange post. Yes, virtual DOM is overhead, much like JIT compilation is an "overhead". But this overhead ultimately translates to better performance because many virtual DOM transformations can be buffered into 1 transformation of the real DOM.
- Rusky 7y agoBetter performance than completely recreating the DOM, sure. But all the time spent constructing and diffing the virtual DOM is pure overhead compared to simply doing that 1 real transformation directly.
- azangru 7y ago> ultimately translates to better performance Better compared to what? For a library like React, which re-renders the DOM tree every time component’s props or state change, virtual DOM with diffing and patching is indeed a better approach as compared to naive re-rendering of the whole DOM. But as Rich Harris said during his talk about Svelte v.3.0, whenever he hears claims about better performance of frameworks based on virtual DOM, illustrated with benchmarks, he runs the same benchmarks with Svelte (not based on virtual DOM), and inevitably gets better results.
- nemothekid 7y ago>But as Rich Harris said during his talk about Svelte v.3.0, whenever he hears claims about better performance of frameworks based on virtual DOM, illustrated with benchmarks, he runs the same benchmarks with Svelte (not based on virtual DOM), and inevitably gets better results. That isn't a fair comparison. Consider this analogy - React is the JVM and Svelte is Rust. JS before either is C. Now it can be shown that in most cases that C is faster than anything on JVM, but in reality it wasn't, and that C code was riddled with bugs. The JIT'd JVM comes a long and guarantees safer and more performance code. Then someone comes a long and says the JIT is overhead rewrites everything in Rust and shows how fast the program is. What's being ignored is the man-years, technology and insights that made Rust possible. The fact of the matter is, (1) code that is written like Svelte generates was incredibly rare and difficult to achieve and (2) Svelte is pretty radical in how the framework is implemented (at a high level, Svelte is essentially doing static analysis on your code to figure out where the DOM is being updated, serving a like-minding purpose of Rust's borrow checker).
- overgard 7y ago> Now it can be shown that in most cases that C is faster than anything on JVM, but in reality it wasn't, and that C code was riddled with bugs. Um, what? Your metaphor breaks down because it doesn’t really connect with reality. The operating system and the browser you typed that in are written in C/C++ because the performance hit of doing that in a language like java would be absurd. Practically every performance sensitive application is still written in C/C++ (games, productivity tools, desktop apps, etc). Rust is, outside of places like HN, just an interesting novelty to like 99.999% of the software industry, and your average java app is glue code between a gui and a database.
- nemothekid 7y agoI had a feeling it was a poor analogy after I submitted it. I'll leave it up, but the analogy doesn't properly convey the point I was trying to get across. This isn't a discussion about Java's relative performance with C++. It's more about the performance gains of properly optimizing your DOM modifications aren't generally possible with a static analysis like Svelte employs.
- cpfohl 7y agoI _think_ it's worth noting that Svelte batches updates too...
- computerex 7y ago> Better compared to what? Better than, presumably the old way of doing things, doing DOM transformations manually in handwritten code. I haven't seen these talks by Rich Harris but they sound very interesting and I'd be very interested to see the performance.
- austincheney 7y agoThe JIT is not overhead and it is in no way related to the DOM. The JIT is a compiler in a VM. The DOM is a standard data model living in memory.