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

Fast, Bump-Allocated Virtual Doms with Rust and Wasm

hacks.mozilla.org

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm

#21

Post by Hello71 »

gambler wrote: post #16

>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM. I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative. Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?

1. This is called "Shadow DOM", it is only supported in the latest browsers. wasm is AFAIK slightly more widely compatible.

2. Even if calls from wasm to the browser are as fast as JS, they will still incur overhead above "internal" function calls.

Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm

#22

Post by cmroanirgo »

It seems memory fragmentation can occur, rather easily, if you hold onto a few of them.

> The disadvantage of bump allocation is that there is no general way to deallocate individual objects and reclaim their memory regions while other objects are still in use.

Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm

#23

Post by sraquo »

gambler wrote: post #16

>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM. I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative. Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?

Because virtual DOM is not the only way to achieve efficient DOM updates, and even within the concept of virtual DOM there could be many different ways to achieve efficient diffing (e.g. React vs Snabbdom). There is nothing special about a particular virtual DOM spec to deserve a place in web standards.

Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm

#24

Post by KuhlMensch »

gambler wrote: post #16

>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM. I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative. Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?

As I understand it - please correct me if I'm wrong!

> HTML itself is definitely declarative

HTML is the markup (not programming) language (which is Javascript). The API to actually change the DOM is imperative. See https://developer.mozilla.org/en-US/docs/Web/API/Node (I don't quite grasp why they felt the need to specify that)

> Why are DOM-diffs something that is done by userland libraries?

I guess if the browser provided primitives to build trees and diff them that would be cool. But I presume using WASM *is getting the native-browser code to do the diffing.

Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm

#25

Post by Rusky »

cmroanirgo wrote: post #22

It seems memory fragmentation can occur, rather easily, if you hold onto a few of them. > The disadvantage of bump allocation is that there is no general way to deallocate individual objects and reclaim their memory regions while other objects are still in use.

The use case in the article does not hold onto a few of them, though- it holds on to exactly two at any time.

Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm

#26

Post by kccqzy »

gambler wrote: post #16

>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM. I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative. Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?

Because once the declarative HTML has been transformed into DOM objects, they are not just dumb data but OO-style rich objects. They have identity and internal state, which may or may not be reflected by their markup (not even innerHTML or outerHTML). For example when you attach an event handler, that object gains this behavior. If perhaps that object has some other change, and a DOM-diff library stupidly deletes the original DOM and add a new one, that could be lost. The same for typed text in fields.

Simply put, the OO nature of the DOM complicates things. If DOM were just a simple recursive tree data structure of which HTML is a serialization, there would be no such issues.

Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm

#27

Post by anonytrary »

Hello71 wrote: post #21
gambler wrote: post #16

>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM. I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative. Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?

1. This is called "Shadow DOM", it is only supported in the latest browsers. wasm is AFAIK slightly more widely compatible. 2. Even if calls from wasm to the browser are as fast as JS, they will still incur overhead above "internal" function calls.

Shadow DOM has nothing to do with this.

Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm

#28

Post by anonytrary »

writepub wrote: post #6

Firstly, congrats on shipping a virtual DOM lib in WASM. Hopefully, frameworks intent on using a V-DOM will greatly benefit from this. Having said that, is a V-DOM required in 2019, if DOM updates are optimally batched, like in FastDom ( https://github.com/wilsonpage/fastdom ). Decades of optimizing browser internals would surely account for not trashing the DOM, if updated optimally. So, is it required?

The optimization VDOMs make is orthogonal to the optimization that batching offers. VDOMs prevent you from having to update more of your tree than is necessary. Batching is a separate optimization, and could easily be applied to VDOM-originating mutations.

Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm

#29

Post by est31 »

gambler wrote: post #16

>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM. I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative. Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?

Virtual DOM is needed to enable a programming model where in each UI iteration, you return the entire UI tree anew. Actually creating a new DOM tree anew would be terribly wasteful, and you might lose lots of state (e.g. half entered text or selected text or something) so instead you do dom-diffing. For some reason, people consider that model to be more hip than the normal one where you take care of updating yourself. Probably because writing code to create the entire UI tree anew is more easy to write, but tbh it's also more wasteful. Classical ease of use vs computation tradeoff.
Post reply on HN