21–30 of 344 posts
This is so true in practice.
First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented. Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library,…
Virtual dom is an implementation decision for performance a developer shouldn't even be very aware of. The main upside to react is that it has a huge ecosystem.
1. Changes to the DOM cost a ton more than executing JS code.
2. So don't feel too bad when a render() gets called that doesn't change anything because the virtual DOM swallows that.
There are other characteristics that are very, very important like build size. VDOM is not worth thinking about.
Honestly I don't understand Svelte. It sounds like it's very good at the things it does but the things it does are not the things I need.
The framework captures dependencies between the reactive "change functions" and underlying variables, and executes the functions whenever a variable's value changes. You can also have dependencies between variables (like computed vars in Vue), and the lib works out the correct order for calculation and execution. All the change functions get queued up and applied in order before the next repaint.
Everything is component based, and there is even a nice kind of inheritance (with lazy, async component loading).
It works rather well. I'd be happy to share it with anyone that's interested! Not open sourcing it yet, as I envisage it would be a full time job to support it!
Edit: the upside of the change functions is that YOU decide how the DOM is updated. It's really quite cool to be able to implement a function like the following and have it run to update this.$dateOfBirth whenever this.data.dateOfBirth changes:
function()
{
this.$dateOfBirth.val(this.data.dateOfBirth);
}
First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented. Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library,…
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.
First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented. Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library,…
Ughh.. that's the point of all modern FE frameworks...
You are putting that description on a pedestal as if that is a unique property of React.
2 things I'm not seeing in the article or in the comments so far: 1) The virtual DOM is an abstraction that allows rendering to multiple view implementations. The virtual DOM can be rendered to the browser, native phone UI, or to the desktop. 2) The virtual DOM can, and should, be built with immutable objects which enables very quick reference checks during the change detection cycle.
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.
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.
I thought this was well known years ago. A better description for VDOM should be 'It's not fast, and is not slow either'. But frankly, what I see in virtual DOM is not about speed. It's a declarative interface, an abstraction. It's more like a blueprint that's easier to interpret across different environments like React Native, WebGL. Even if you don't need any of these cross-platform benefits it's still good for tes…