3 ms·

Curious as to what the JS bridge overhead is like for both latency and throughput. What would the performance look like if you tried to serialize DOM updates ov

Curious as to what the JS bridge overhead is like for both latency and throughput. What would the performance look like if you tried to serialize DOM updates over the bridge and replay them on the JavaScript side so that you could build DOM UIs? Have you measured # of updates per ~16ms? (I know there is some proposal that might allow WASM to interact with the DOM directly too, but I don't know how likely it will be merged.)

janpaul123 5y ago
Overhead of calling into JS from Wasm is very low; DOM calls are no problem since the DOM call itself is much slower than the overhead of switching from Wasm to JS. See e.g. this article from ~4 years ago: https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a... There are even some libraries that try to mimic React directly from Rust, such as https://yew.rs/ https://yew.rs/ (though in my experience they can be a bit harder to use than Zaplib, since they require you to learn about traits, closures, etc, and tend to also run into borrow checker issues more often -- all of those are things we try to avoid having to learn in Zaplib!)