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

291–300 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#291

Post by andrekandre »

Tehdasi wrote: post #231
rayiner wrote: post #85

Only ever having used MFC and Swing, this seems odd to me. A diff of the entire DOM on every state change? You never see anything like that in native toolkits. ELI5: What problem is that solving?

The problem it's solving is the DOM being unsuited to writing the kind of applications that MFC and Swing are used for writing. (which, for the web, is a SPA)

isn’t this pointing to more of a fundamental problem with how browsers/html/document model are designed/implemented than anything else?

html was originally a document format, not an app framework, and i think all of these frameworks (large and small) are just workarounds when what we really need is a fundamental re-imagining of what the browser should/could be.

sometimes i wonder if alan kay was right when he said the browser should have been basically just byte-code interpreter[1]...

[1] http://www.drdobbs.com/architecture-and-design/interview-wit...

Re: Virtual DOM is pure overhead (2018)

#292

Post by tomaskafka »

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…

Few years ago I just did a 'react + redux in jquery' on a smaller project. A state of app was in a single object (= super easy debug, undo or save), any user action generates a state delta (which properties of state needs changing), and a central dispatcher updates the UI according to state changes. Quick and painless.

Re: Virtual DOM is pure overhead (2018)

#293

Post by weberc2 »

ppeetteerr wrote: post #286
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?

I would argue that the state of the global model includes some information about the state of a widget (e.g. selected="true") and some state is unique to the widget itself (hover). The trick here is how do you reconcile those two states when both have a copy of the data. For instance, the holds its own state and you hold the value in the global state. When a user types a character into the input, the input hold a cop…

If I understand correctly, the distinction between immediate mode GUI and retained is that in the former, there aren’t stateful widgets so there is no copy to reconcile.

Re: Virtual DOM is pure overhead (2018)

#294

Post by kgwxd »

kgwxd wrote: post #28
thoman23 wrote: post #12

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.

On point #2, ClojureScript not only provides immutability out of the box, but also has libraries for replacing JSX with the same stuff everything else is built with. It's an insanely beautiful way to work with React.

There's a good discussion about this article on the Clojure Reddit sub: https://www.reddit.com/r/Clojure/comments/bqh0z4/virtual_dom...

Re: Virtual DOM is pure overhead (2018)

#295

Post by pier25 »

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…

The idea that the DOM is slow and that v-DOM makes it faster is completely ridiculous. V-DOM can only optimize user land code. DOM manipulation will always be at the mercy of the browser implementation.

Yeah, it is a better approach than badly optimized jQuery style code, no shit, but it's not really the fastest approach either as others like Svelte and Imba have demonstrated.

Re: Virtual DOM is pure overhead (2018)

#296

Post by atan »

oraphalous wrote: post #79
Chris_Newton wrote: post #65

Earlier quoted context omitted.

In short - the DOM was often used to store state. And this just isn't a very efficient approach. By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around. I think the basic premise of the article here is correct. The important development with React that hadn’t previously been widely seen in front-end, JS-based w…

>By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around. My claim is that this isn't a good representation of the FE culture as a whole - even if there were islands of enlightment out there. Hell, just about all of the enterprise codebases I get contracted to work on are STILL do state management the old way. S…

> I'm saying that OP could do this without crapping all over React's contribution

What are some specific quotes from the article that you feel are "crapping all over React's contribution"? Genuinely curious, because I don't take the tone of the article that way at all.

Re: Virtual DOM is pure overhead (2018)

#297

Post by atan »

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 compared to React's runtime library approach.

I initially had a similar concern, but so far, the opposite appears to be true. The Svelte compiled code is quite readable and easy to follow, and because there is no runtime, it's much easier to walk through exactly what is happening. With a complex runtime, it can sometimes be difficult to figure why something isn't working as expected without having a deep understanding of the runtime codebase.

Re: Virtual DOM is pure overhead (2018)

#298

Post by atan »

Lowkeyloki wrote: post #271
dahfizz wrote: post #235

Earlier quoted context omitted.

> 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.

> 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.

Are you saying the original source code hides complexity that is present in the generated code? If so, I guess that's the whole point, but then a runtime framework also hides lots of complexity that your code doesn't have to manage (which, again, is the entire point of using a framework).

> It's much harder to debug code that doesn't resemble what you wrote in the first place.

With a runtime framework, there's lots of code running that isn't your code, which can also make debugging difficult. With Svelte, at least the generated code is fairly straightforward and easy to step through. In many case, I think it's actually easier, not harder to debug.

Re: Virtual DOM is pure overhead (2018)

#299

Post by atan »

ralphstodomingo wrote: post #205
ng12 wrote: post #23

I keep hearing this and find it really hard to care about. Runtime performance is not a bottleneck for me. Once in a blue moon I'll have to optimize a React component with shouldComponentUpdate but otherwise I have no performance concerns even on old browsers. 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…

I feel as if Svelte came at the wrong time. These days, when most people know either React or Vue or some other thing, and computing devices are performing better over time, there's diminishing returns on performance optimization. Sure, you do a bit of it, and then you're often better doing something else, like enhancing developer experience for example. I really like the idea, and will play around with it, but fat c…

> Sure, you do a bit of it, and then you're often better doing something else, like enhancing developer experience for example.

Aside from its performance optimizations, arguably one of the biggest selling points of Svelte is its developer experience (which is enabled by it being a compiler). See https://svelte.dev/blog/svelte-3-rethinking-reactivity. And because only the features used in your components get included in the final bundle, the framework is free to add nice extras (like its transitions/animations system) without negatively impacting apps that don't need those extras.

Re: Virtual DOM is pure overhead (2018)

#300

Post by atan »

_0w8t wrote: post #166

Direct manipulations of DOM are expensive. It is vastly more cheaper to create or update JS object than create or manipulate DOM node. So the claim that VirtualDom is always an overhead is not true. The diff algorithm can give a set of DOM operations that are less expensive than typical sequence of manual mutations. So virtual DOM can be faster if savings from less DOM operations are bigger than extra JS work. Surely…

I'm not sure you understood the article. The Svelte compiler does in fact generate code that performs "carefully crafted direct DOM mutations," though it is not hard to maintain, because the compiler handles it. Given code that already knows exactly which DOM updates to make, virtual DOM would indeed be pure overhead.
Post reply on HN