When you start learning about the frontend world, you’ll almost immediately stumble across the term “Virtual DOM”.
Most of the popular frontend fr...
For further actions, you may consider blocking this person and/or reporting abuse
I think the future is going towards much different solution:
javascript.plainenglish.io/javascr...
RiotJS came 6th overall - nice! I've always thought it was great - and ridiculously underused
I'm not pushing Svelte (have never used it) - but the virtual DOM isn't necessarily the best or fastest way to go...
svelte.dev/blog/virtual-dom-is-pur...
Svelte does not use virtual DOM and performs better depending on the scenario, the needs, the implementation of the front-end framework and the implementation of the code and of course, the machines running that
Let's imagine you're a painter and the client asks you to fix just one thing, but you decide to redraw the whole painting instead and then praise Photoshop for allowing you to do it digitally and save you canvas and materials, that otherwise would be wasted.
VDOM is made to avoid full render on a partial change. It can never be faster than a manual update to each particular DOM object in question.
Nice one!
Everything about the VDOM was explained very understandable and clear. Thank you for the additional information about the browser rendering. I've read several different articles, which told, that the heaviest part is the painting process, but they did not explain why the content painting is so expansive. The information about the layout stage and the painting stage were minor details, which filled the gaps.
I think it would be better to compare the performance of a VDOM-based application to the performance of the same application written in a framework/library using another optimization technique.
Still, it was a very informative and interesting article!
and your feedback has differentiated the article from others. nice job Lilit.
Nicely written and clear.
It seems to me that fast is marketing language, not technical. And that it was fast compared to some specific implementations of bindings that predated it in a context with similar assumptions about SPA architecture, but that it is not fast in absolute terms.
Because there are a lot of caveats. What about the large amount of JS required up front and how that trades away startup performance? What about the need for SSR and the uncanny valley of hydration? What about the loss of HTML's historically demonstrated ability to stream and gracefully degrade? What about the poor performance of virtual DOM based libraries on mobile devices? Etc.
But that'd make for a much longer and less satisfying article.
I would love to see maybe a section at the end discussing the nuance of Virtual DOM, for example, discussing how imperative DOM manipulations will be faster and compiled js lib performances
Great 👌
Thanks mate ✨
thanks for explaining it Domagoj.
Thank you,Nice Explanation 👏 👏
In fact, on the mobile side, the real performance bottleneck is the WebView initialization time, and the HTTP resource loading time. JS is cheap
Thanks mate!