Can someone remind me why virtual DOM was/is desirable in the first place and why updating the DOM directly is desirable now?
If I understand correctly react elements are created in memory, and only upon "render" it is turned into the actual DOM. During render in react, it does the tree diffing and state management. Supposedly manipulating the actual DOM directly is "heavy" hence delay/pruning the virtual DOM tree first then rendering would be beneficial? Then why is it working with DOM directly is desirable? And am I right to assume that "without virtual DOM" means work with DOM directly? Someone in the comment mention that Svelte is without vDOM already. Is there some design document that I can refer to, like the reconciliation engine used in react https://github.com/acdlite/react-fiber-architecture
I don't know why VirtualDOM is suddenly getting a bad rep. The reason you often want something like a VirtualDOM is so that you can "pre-process" your DOM updates in-memory so that the actual updates, which are computationally expensive for the browser, can be done more efficiently.
I suspect, but this is just my personal conjecture, that the reason VirtualDOM is suddenly falling out of favour is a reaction against very bloated JavaScript applications and the complexity that underlies working with current popular frameworks and libraries. Some are starting to question whether we are working with solutions to actual problems faced or whether we've adopted approaches that were intended to solve a specific problem faced by some but are inefficient for simpler applications.
As always, be an engineer. Consider all relevant factors before choosing a set of tools or marrying yourself to one technology vs another.
I feel like I live in the Twilight Zone because to me data visualization with a VDOM seems much smoother than without like in Svelte even though data visualization is supposed to be a strong point of Svelte.
As someone who has only really got up to speed with React in the past year, I can't understand why people hate on React. Much of the hate has to be residual hate for Meta.
Svelte to me seems like a mess. $:variables seems like an absolutely terrible idea. Maybe it is a good idea if you are a genius but I assure you I am not and can do absolutely confusing and crazy things with $:variables.
> As someone who has only really got up to speed with React in the past year, I can't understand why people hate on React.
I'm not sure where the people you are hearing from are coming from, but I can tell you why I personally hate on React.
It has nothing to do with VDOM or its underlying tech, it is its design.
React gets treated as if it's a framework but is just a view library that gives you the ability to create components.
However, even that ability is rather lacking compared to a framework like Angular. Now, people hate on Angular too for various reasons but to stay on topic I won't digress into that.
Things I'm missing OUT OF THE BOX (yes I know there are 12 billion libraries "for that" that came out this week alone) with React are:
- View encapsulation (styles bound to components)
- A templating language that lets me separate a component's markup from its JavaScript
- Native typescript
- Inversion of Control / dependency injection framework
- Native routing that lets me configure my routes as metadata instead of having to use components, which ought to be strictly view / presentation only.
Working with inherited React code often reminds me of working with PHP in the 90s. Lots of markup mixed with lots of logical operations written by developers who don't know the first thing about separation of concerns, design patterns or layered architecture but the barrier to entry is low so they picked it up and were able to get stuff done with it despite not having any guidance what-so-ever on how to write maintainable code with a long shelf-life.
My very rough understanding is: It's nice to be declarative and just re-render everything on every state change. This is impractical to do with actual dom, but maybe works good enough with vDOM and dom diffing. Still, doing vDOM and them actual DOM updates is more work than just doing the DOM updates that are needed. And I guess tools like svelte let you be declarative and only make the necessary DOM updates while skipping the vDOM.
Thanks! This helped lot. Now having taking a gentle look at svelte, I think it is very smart. Instead of diff-ing the virtual component tree, it is maintaining a dependency of statements behind the scene by providing a reactive declaration. Upon each event, the re-run the whole tree of statements, then update the DOM directly with the result of those statements, hence no need heavy manipulation of DOM nor diff-ing of large in memory object. I've only just started to look at svelte though, so could be very wrong. But again thank you so much for you pointer, everything just clicked suddenly.
The reason VDOM was desirable is that React's "View is the function of the State" paradigm has a great developer experience, and VDOM was just the easiest way to implement it without sacrificing performance too much.
Now that we played with the easiest implementation of V = f(S) for a few years, we're moving on to more complex implementations, which have their own benefits. Namely, less overhead and better DX.
Frameworks like Svelte are moving good chunk of state management accidental complexity out of your app code and into the framework itself, where it actually belongs (i.e. where it is essential).
> and VDOM was just the easiest way to implement it without sacrificing performance too much.
Kind of. Virtual DOM nodes are extremely lightweight compared to real DOM nodes, so manipulating a VDOM to determine what updates need to be done to the DOM, instead of doing all interactions/comparisons directly with the DOM, had a big performance boost.
No offense, but this sounds like typical React-cult nonsense.
You're still making the same amount of DOM manipulations in the end. And you don't need VDOM to figure out which manipulations are necessary.
There are some potential optimizations VDOM can allow (e.g. batching/deduping), but there's nothing "lightweight" about it. Lightweight overhead is still overhead.
When we started using React in 2015 it was in one of the official explanations (or semi-official, like a blog post by someone working on it). The page I remember involved comparing the number of attributes each node has in the vDOM vs the real DOM and its legacy attributes, and was about both about memory usage and how it restricts the search space by just not allowing most of those legacy attributes.
It's easy to forget nearly 10 years on, but React came out when Backbone.js with mustache templates was rather common, and React was a LOT easier to manage. The other popular frameworks at the time were Ember and Angular 1, which were quite a bit larger/heavier. By comparison, React could be adopted in a much more incremental fashion. React was super easy to adopt (and it still is, but there's a lot more of an ecosystem around it now which makes it feel much more like a framework).
If I understand correctly react elements are created in memory, and only upon "render" it is turned into the actual DOM. During render in react, it does the tree diffing and state management. Supposedly manipulating the actual DOM directly is "heavy" hence delay/pruning the virtual DOM tree first then rendering would be beneficial? Then why is it working with DOM directly is desirable? And am I right to assume that "without virtual DOM" means work with DOM directly? Someone in the comment mention that Svelte is without vDOM already. Is there some design document that I can refer to, like the reconciliation engine used in react https://github.com/acdlite/react-fiber-architecture