Hacker News Reader

Comment by Rotten194 | Hacker News Reader

I thought DOM manipulation from WASM was pretty expensive because it needs to be bridged through JS -- is that still true?

View on HN

You still need to go call into Javascript to do any kind of DOM manipulation. The solution I used for wasm-forth (a forth implementation targeting wasm), is to have a js "interpreter", implemented as a single function, that executes a sequence of DOM manipulation instructions, represented as an array of integers. On the forth side, the instructions are generated by a virtual DOM library: as the virtual DOMs are diffed, instead of manipulating the DOM directly it generates a sequence of opcodes to send in one go to the Javascript interpreter.

The cost of the Javascript bridge is minimal: it's a single function call to render or update a whole page, and there is no serialization/deserialization involved since both languages can understand arrays of integers natively.

This is a really neat idea! Was there an inspiration for this? I think something like this could be very useful!

That’s basically what ReactNative does.

Your general approach is correct. Glimmer uses a similar approach, where it compiles templates to bytecode. https://github.com/glimmerjs/glimmer-vm/blob/master/guides/0...

NB: You need to update strings in the DOM outside of the limited context of wasm-forth, so there is still serialization and deserialization involved, or at least string buffer views.

Unfortunately it is, you may want to have a look at: https://krausest.github.io/js-framework-benchmark/current.ht...

Filter for wasm frameworks like “Yew”.

There's wasm benchmarks that don't trail much behind vanilla JS, though.

There’s a lot of variance here. See https://ivanceras.github.io/sauron-perf/ too.

New versions of libraries, new optimizations in browsers... the numbers are changing all the time.

Reply on news.ycombinator.com