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

271–280 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#271

Post by Lowkeyloki »

dahfizz wrote: post #235
Lowkeyloki wrote: post #11

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,…

> There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that... How is this different than the "non-trivial" transformations that V8 makes to actually compile and run your code? Does svelte do unpredictable / unexpected things? Don't you make runtime calls to…

I don't actually have a strong aversion to compilers. I use tools like Babel and Webpack regularly. However, I've seen the types of transformations the Svelte compiler does and they tend to hide complexity, making it harder to trace and debug code at runtime. Source maps can only do so much. It's much harder to debug code that doesn't resemble what you wrote in the first place.

Re: Virtual DOM is pure overhead (2018)

#272

Post by Klonoar »

ljm wrote: post #242
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…

I love how many people there are in this thread that somehow avoided the jQuery hell a lot of us battled against. I was involved in that, mostly from when my paycheque involved throwing together websites in Drupal 6. Holding that architecture together was trouble enough without having to also care about the frontend, we were only scripting it. The idea of the HTML being considered an 'app' was utterly alien to me and…

Not just jQuery... we had some crazy times with Dojo, MooTools, and so on. Closures and "this" being screwy (IMO) led to junior developers spending an insane amount of effort shoving things into DOM elements because it was a free global store that you could inspect and work with.

The VDOM is cool, but React (& co's) appeal is the streamlined development tooling, approaches, and ecosystem where there's a mostly agreed upon way to do things.

>I fondly remember the short period of time where we had post after post attempting to explain what a closure is, because for most of the authors back then the concept of a function pulling outside variables into its scope was utterly alien to us. Even now this practical meme persists[0].

My favorite was actually when we needed a groundswell movement to make people realize that $() wasn't a variable, but a function call, and for complex selectors (before querySelectorAll, when Sizzle was a far more complex beast) you really wanted to cache it. Or, getting people to stop attaching event handlers to every row in a 10k row table, and to just match the click to the row once.

It really does feel like people have forgotten just how rough the gap was back then.

For real though. I feel comfortable building something in VanillaJS... e.g, building up a fragment before shoving it into the DOM, architecting how updates are applied, etc. This is all stuff that was hard learned, and became easier the more I stepped outside JS later on. I would in no way want a junior trying to do this without learning the better practices found in React - _not_ because they need the crutch, but because I learned those some lifecycle methods and such from Cocoa/UIKit and you need a frame of reference to internalize it all.

Re: Virtual DOM is pure overhead (2018)

#273

Post by weberc2 »

weberc2 wrote: post #249
barrkel wrote: post #222

Earlier quoted context omitted.

Before anybody runs away and thinks there's a fundamental insight here, I have to say that all that's really changing is who owns the retained model: application or UI library. I mean retained by contrast with immediate, as in the early DirectX jargon. By retained model, I mean the source of truth as to the current state of the UI. Games normally use an immediate mode API, but they still render the UI from a model; i…

How are these other state concerns you mention (e.g., focus) handles in immediate mode GUIs? Do the components retain those states or do you keep a separate model for those states that needs to interact with the application model? If so, how is that interaction wired up?

S/handles/handled

Re: Virtual DOM is pure overhead (2018)

#274

Post by Klonoar »

stolsvik wrote: post #262
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…

Why don't the credit of "changing the culture of how we thought about state management on the frontend" go to AngularJS? At least Angular is what changed it for me, and it is the oldest of them.

Because Angular wasn't the first? Angular 1.0 also left an eternally bad taste in many peoples mouths.

Re: Virtual DOM is pure overhead (2018)

#275

Post by oblio »

hyperdimension wrote: post #216
DonHopkins wrote: post #176

Earlier quoted context omitted.

Teach the Controversy [TM]! https://en.wikipedia.org/wiki/Parity_of_zero#Education Claims made by students: "Zero is not even or odd." "Zero could be even." "Zero is not odd." "Zero has to be an even." "Zero is not an even number." "Zero is always going to be an even number." "Zero is not always going to be an even number." "Zero is even." "Zero is special." https://en.wikipedia.org/wiki/Teach_the_Controversy

Just so you know (not just for this comment)--you are my favorite HN user. Everything you post is either funny, quirky, or extremely interesting (mostly all of the above).

And, to add to this (I'm not being snarky), he could be the father/grandfather of many HNers. I recall one of his comments about how he was doing stuff on computers in 1965.

We need more old coders around!

Re: Virtual DOM is pure overhead (2018)

#276

Post by sam0x17 »

davidjnelson wrote: post #270
sam0x17 wrote: post #134

Earlier quoted context omitted.

My god, it finally all makes sense! And this is why I've been developing all my modern web applications as essentially an S3 bucket of flat HTML with vanilla javascript and jquery sprinkled in sitting behind cloudfront, connected to a fast API built of cloud functions / lambdas written in crystal/rust/etc. I use a custom routing system (I have S3 set up to respond with a 200 at the index in the event of a 404, so I h…

> perfect automatic horizontal scaling Nothing is perfect, but aws aurora serverless auto scales compute and storage for MySQL https://aws.amazon.com/rds/aurora/serverless/

Last time I checked it has a large entry level cost. When will they learn.

Re: Virtual DOM is pure overhead (2018)

#277

Post by beders »

writepub wrote: post #168
beders wrote: post #164

It is simply mind-boggling how much effort the JS community has put into working around the performance properties of a document layout engine to make it 'interactive' and 'responsive'. With only 3 major rendering engines left standing, where is the concerted push to turn these document renders into general purpose, fast, desktop-quality rendering engines? Back to Svelte vs. React vs. Reagent vs. Vue.JS vs. Angular v…

> where is the concerted push to turn these document renders into general purpose, fast, desktop-quality rendering engines The DOM is fast enough for desktop apps @60 or even 90 frames per second, especially of you follow best practices (no framework required)

If it is fast enough, why is everyone optimizing?

Re: Virtual DOM is pure overhead (2018)

#278

Post by kevingadd »

Sawamara wrote: post #139
pier25 wrote: post #66

Earlier quoted context omitted.

The cost of the DOM operation is the same. The difference is that React batches the changes to reduce the number of operations whenever possible.

Ew, not really. Even the getters can be performance-heavy in DOM-land. If you store your data in JS-land, and only diff against that, you never need to touch the dom for anything, except the endpoint insertions. At worst , it is matched evenly by any sort of custom vanillaJS+Dom manipulation tool (which needs to be perfectly well written, and hand-crafted to match what you are currently working on). At best, its seve…

You overestimate the cost of modern DOM operations. It's a battle between your virtual DOM (to optimize DOM operations without lots of diffing overhead) and the native DOM (which is frequently a bunch of JS that can get inlined and avoid duplicate work)

Re: Virtual DOM is pure overhead (2018)

#279

Post by writepub »

beders wrote: post #277
writepub wrote: post #168

Earlier quoted context omitted.

> where is the concerted push to turn these document renders into general purpose, fast, desktop-quality rendering engines The DOM is fast enough for desktop apps @60 or even 90 frames per second, especially of you follow best practices (no framework required)

If it is fast enough, why is everyone optimizing?

I hope you read the original article, that clearly lays out the (non) optimizations being done in VDOM.

In any compute environment, doing more than necessary spins CPU cycles wastefully. I believe the optimizations you speak of try to limit this work to the least possible, by telling on the framework's Dev world. But this is surprisingly easy to achieve without frameworks, see [1] and [2]

[1]: https://github.com/wilsonpage/fastdom

[2]: https://youtu.be/sFMpS2_GqQc

Re: Virtual DOM is pure overhead (2018)

#280

Post by mpfundstein »

weberc2 wrote: post #273
weberc2 wrote: post #249

Earlier quoted context omitted.

How are these other state concerns you mention (e.g., focus) handles in immediate mode GUIs? Do the components retain those states or do you keep a separate model for those states that needs to interact with the application model? If so, how is that interaction wired up?

S/handles/handled

You can edit your posts after you have posted them
Post reply on HN