Fast, Bump-Allocated Virtual Doms with Rust and Wasm
hacks.mozilla.org
Fast, Bump-Allocated Virtual Doms with Rust and Wasm
1–10 of 62 posts
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#2[deleted]
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#3"Fist-Bump allocated Virtual Domination with Rust by WASMs" sez my lizard brain...
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#4Yes, I was thinking web developers, rather than using rust and wasm directly, would first get the benefits when the libraries they use start moving the heavy duty parts to it. Can't wait to see if someone uses this for building a react-like framework.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#5Yes, I was thinking web developers, rather than using rust and wasm directly, would first get the benefits when the libraries they use start moving the heavy duty parts to it. Can't wait to see if someone uses this for building a react-like framework.
Would be interesting to see if React could simply integrate it.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#6Firstly, 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?
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#7Firstly, 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?
They are only batched if they are all updates or all reads, but not if there's an interpolation of both.
Even if the browser optimizes it with an optimum update strategy, it doesn't matter if a developer who doesn't know better forces thrashing to occur. Virtual DOM libs help structure code in such a way that idiomatic code falls into the pit of success.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#8Firstly, 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?
To build a client-rendered site? No, vdom is not required. To build a tool with multiple render targets? Maybe, or at least something similar.
In particular, the trend of rendering a page via a node.js server, and delivering the rendering logic to the client so that subsequent renders do not require a full round-trip is pretty alluring if you're building something more complex than a blog or run-of-the-mill ecommerce site.
https://catberry.org/ is one of the older examples I can think of that do the above sans vdom, though now that I look at it again, it seems to have changed quite a bit in the years since I first found it.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#9Yes, I was thinking web developers, rather than using rust and wasm directly, would first get the benefits when the libraries they use start moving the heavy duty parts to it. Can't wait to see if someone uses this for building a react-like framework.
The Rust Wasm working group agrees, and that's why they've been pursuing a strategy of building libraries, rather than full front-end frameworks. There are some people who are doing that, and now that the "build a library in wasm" story is going pretty well, there are some plans to move into that space too (https://rustwasm.github.io/2019/03/12/lets-build-gloo-togeth...). But almost all of the previous work has been for libraries.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#10Firstly, 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?
It’s never been required — and is usually substantially slower – but a virtualdom may be worth the overhead because it avoids the need to organize those updates. Most cases aren’t performance sensitive to the point where that’s the deciding factor in a decision.