Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

Post reply on HN
Print view View original

151–160 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#151

Post by 2T1Qka0rEiPr »

vfc1 wrote: post #144

Angular also works in a somewhat similar way, there is also no virtual DOM. Instead, the modern compiler is used at build time to generate what looks like a change detection function and a DOM update function per component. These functions will detect changes and update the DOM in an optimal way without any DOM diffing. However, because Javascript objects by default are mutable, after each browser event Angular in it…

Thanks for the write up - it's a very succinct explanation of how Angular works in comparison.

I found the original article to be a really good read, and the Svelte approach in general seems rather neat. I do however find that in this current front-end framework sphere, there seems to be a huge amount of religiosity and one-upping going on.

I hear routinely (on-line and off) developers vocalising some anti-[jQuery,angular,etc.] mantra, which to be honest saddens me. Yes the jQuery approach was flawed in so many ways in comparison to the modern frameworks. Yes Angular 1.x was flawed in many ways compared to what we have on offer today. But those tools were still great improvements on what we had before (for anyone who knew the DOM-API standardisation nightmares pre-jQuery, or state management / testability woes pre angular/react).

Svelte may take us down the next path, and if it allows us to produce better, smaller, more testable code then it has my full backing. But I think as a community we need to strive to be less polarising - from my perspective its likely to be mostly reductive, and lead to even more JavaScript fatigue.

Re: Virtual DOM is pure overhead (2018)

#152

Post by radicalbyte »

jasonkester wrote: post #119
oraphalous wrote: post #54

I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced. Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child…

the DOM was often used to store state. Every once in a while I'm reminded that I'm mostly disconnected from the way "most" people build things. Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did. But wow. I've been building javascript-heavy web stuff since the mid 90's and it had never occurred to me to do that. You hav…

That's just a symptom of Javascript being the entry-level language. You can be sort of productive without ever understanding how anything works.

Where these frameworks really come into their own is when you want to create reusable components and share them outside a team. jQuery did a good job with their plugins back in the day but Angular 2 (and React, and soon native Web Components) so that far better.

Re: Virtual DOM is pure overhead (2018)

#153

Post by LoSboccacc »

jasonkester wrote: post #119
oraphalous wrote: post #54

I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced. Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child…

the DOM was often used to store state. Every once in a while I'm reminded that I'm mostly disconnected from the way "most" people build things. Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did. But wow. I've been building javascript-heavy web stuff since the mid 90's and it had never occurred to me to do that. You hav…

I mean, I use to store data in my model and have the controller doing the rendering like anyone else that has some kind of experience on how ugly the opposite would become, but to outright demonize state within html seems quite misguided as well

there are things that are massively annoying to do without sneaking a data-uuid and data-type here and there, like drag&drop or specific customer requests - if anyone has ever written a cms, imagine the customer coming and telling "I want this product image in black and white" - if you had data attributes around, it's a css two liners, if you didn't because you're trapped into a either-or mindset, you have to also add the image-bw class on the rendering code with "customer ==" and "product ==" checks

Re: Virtual DOM is pure overhead (2018)

#154

Post by Sawamara »

Mikushi wrote: post #143
Sawamara wrote: post #136

I was running some quite complex UI systems in several of my projects with vanillaJS, cached DOM elements, all that jazz. Nothing like VDOM. Then eventually, it started to finally bog me down. Like rendering an inventory in an RPG system where you can buy stuff from the vendors: I started to get dissatisfied with change operations that lasted upwards to 2-3ms in a bad day. Then I started caching even more DOM element…

Not to be grating but your problem sounds more like using the wrong tool for the job. DOM is not made to render video game UI, it is a bad tool to do so as you discovered yourself.

Tell that to Guild Wars 2. (https://mithril.js.org/framework-comparison.html)

But putting even those games aside which use webview for UI, there are still video games made inside the browser, and for those, having sub-1ms rerender times with React is perfectly reasonable. We could get into immediate mode vs retained mode debates right about here, but that is a slightly different topic :D

Re: Virtual DOM is pure overhead (2018)

#155

Post by fauigerzigerk »

vfc1 wrote: post #144

Angular also works in a somewhat similar way, there is also no virtual DOM. Instead, the modern compiler is used at build time to generate what looks like a change detection function and a DOM update function per component. These functions will detect changes and update the DOM in an optimal way without any DOM diffing. However, because Javascript objects by default are mutable, after each browser event Angular in it…

>The current change detection and DOM update mechanisms made available by modern frameworks virtual DOM or not are more than fast enough for users to notice, including on mobile and once the application is started. What we need is ways to ship less code to the browser [...]

I wonder how it affects battery usage though. Downloading the code doesn't happen as often as running the code, if it's really an app and not content needlessly packaged as an app.

Re: Virtual DOM is pure overhead (2018)

#156

Post by Tade0 »

QuadrupleA wrote: post #32

So glad to see this article, I've long wondered how this "virtual DOM is faster" myth got accepted as gospel when clearly it's pure overhead, compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps). Can't speak to the svelte approach due to inexperience with it, but good to see this myth challenged - react.js is fine but I worry there's been a ca…

react.js is fine but I worry there's been a cargo cult mentality around it,

And also an actual personality cult directed at some key people.

Re: Virtual DOM is pure overhead (2018)

#157

Post by Tade0 »

mruniverse wrote: post #107
QuadrupleA wrote: post #32

So glad to see this article, I've long wondered how this "virtual DOM is faster" myth got accepted as gospel when clearly it's pure overhead, compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps). Can't speak to the svelte approach due to inexperience with it, but good to see this myth challenged - react.js is fine but I worry there's been a ca…

Yeah, you're right. But then you get others now trying to say "No no no, you have it all wrong. We didn't really say VDOM was faster. You misunderstood."

I hate this type of argument - blaming the receiver while at the same time taking no responsibility for their poor wording.

Re: Virtual DOM is pure overhead (2018)

#158

Post by nailer »

sam0x17 wrote: post #137
cryptica wrote: post #133

Earlier quoted context omitted.

complexity also kept me away from React. The main reason that it got popular is because it's by Facebook and they know how to manipulate people to use certain products over others (that's their entire business). There have always been simpler and cleaner alternatives. If React was not by Facebook, it would not have gotten popular at all except as a 'cool hack/experiment' - Nobody would have seriously tried to incorpo…

Convenience is to be taken with a grain of salt, though. In the node.js world, "is-odd" can be a package, and it can have 926,000 weekly downloads and 22 dependents.

Makes sense, you don't want to write your own tests for handling zero.

Re: Virtual DOM is pure overhead (2018)

#159

Post by the_duke »

muxator wrote: post #92
andrewfromx wrote: post #39

Earlier quoted context omitted.

tell me about it! Or, heaven forbid, just make the user get the entire html page rendered from server after every click like it's 2003 or 2004!

Which sometimes is not bad at all. Ever tried to ctrl-click an interface element (a navigation button, a menu) because you want to open its view in a new window? A lot of (admittedly badly coded) "modern" web apps ignore basic web idioms (like hyperlinks) and assume as unique single user workflow the one its designer tought the app (and the only one he tested).

A nice example of this: with the new Reddit interface, only visible comments are rendered, so you can't use your browser search functionality to search all comments on the page, just the ones currently in the viewport.

Re: Virtual DOM is pure overhead (2018)

#160

Post by PudgePacket »

dmix wrote: post #86
tylerhou wrote: post #59

Earlier quoted context omitted.

> In my experience, as your app grows, the amount of time you spend on dom reconciliation becomes negligible compared to your own business logic. In this case, having a framework like React (especially with concurrent mode) will really help improve perceived user experience over a naive compiled implementation. In my experience, the exact opposite occurs. If there is ever any heavy computation I need to do, I usually…

Same, the only time I've run into performance issues with Vue after building many very complex deeply nested components prior to this was one which ground to a halt on re-rendering because I was simply rendering too many elements into the DOM with their subsequent watchers filling up memory. After hours of combing through frames of the memory profiler and seeing only highly concurrent framework calls the only solutio…

You could use svelte just for that heavy component and see if it makes a difference? Svelte compiled output is very small (only brings what you need) so you can quite easily embed it without dragging along a whole extra framework.
Post reply on HN