
JavaScript to Rust and Back Again: A Wasm-Bindgen Tale - steveklabnik
https://hacks.mozilla.org/2018/04/javascript-to-rust-and-back-again-a-wasm-bindgen-tale/
======
piercebot
The title "Javascript to Rust and Back Again" had me believing that this would
be a tale of how Rust was abandoned in favor of Javascript! I'm so glad to see
we're actually talking about wasm interop

~~~
kibwen
At our local Rust meetup we have someone who's gotten WASM running on a
microcontroller, so maybe that's not entirely unrealisitic. :P

~~~
jamesmunns
Wait, who was that?

~~~
vardump
This is somewhat related, although embedded here means embedding _interpreted_
WASM into a CLI application.

Similar method might be doable on an MCU.

[https://fosdem.org/2018/schedule/event/rust_embedding_wasm/](https://fosdem.org/2018/schedule/event/rust_embedding_wasm/)

Then there's "WebAssembly interpreter in C":

[https://github.com/kanaka/wac](https://github.com/kanaka/wac)

Looks like it might be good enough for implementing WASM "scripting" support
in smallish environments.

~~~
steveklabnik
[https://crates.io/crates/parity-wasm](https://crates.io/crates/parity-wasm)
is an interpreter in Rust; there's some really interesting stuff happening
with it in various forms. One of the most... extreme is
[https://www.reddit.com/r/rust/comments/88sxah/nebulet_can_no...](https://www.reddit.com/r/rust/comments/88sxah/nebulet_can_now_call_external_functions_from_wasm/)
(There are some more production-aimed things as well.)

I think this idea has a lot of merit, overall, exactly as you say: kind of
like a Lua.

------
vvanders
> Faster-than-JS DOM performance

...

> The wasm-bindgen code generation has been designed with the future host
> bindings proposal in mind from day 1. As soon as that’s a feature available
> in WebAssembly, we’ll be able to directly invoke imported functions without
> any of wasm-bindgen‘s JS shims.

Sweet.

Once again, Rust team knocking it out of the park.

~~~
jerf
"Faster-than-JS DOM performance"

That will be when the clock starts ticking on Javascript.

Who'da thunk one language might eventually eat both a significant chunk of C
_and_ a significant chunk of Javascript someday?

I'm _not_ saying Rust will completely eat Javascript; there is no chance that
all web developers would or even necessarily _could_ switch to Rust. But the
framework war will take a _very_ interesting turn if Rust gets faster access
to the DOM than JS can provide, and is _also_ a faster language than JS, and
also tends to afford the use of more efficient constructs that Javascript can
provide (i.e., can't do anything about cache coherency in JS, can't manage how
much copying you do in JS directly, etc.). And if the ball starts rolling on
this, the browsers will start doing things like allowing WASM to register
correctly-typed events handlers that don't have to be marshaled into JS and
back... it's been a long road and there's a long road ahead still but do I see
the glimmer of a world in which browsers can actually perform within a factor
of 2 of native UIs?

~~~
maxxxxx
Is JS even the speed problem or is it banging on the DOM all the time?

~~~
vardump
It might help to think speed as lower power consumption.

So yes. As long as cellphones and laptops need a battery.

~~~
maxxxxx
I understand. My question is whether it's the Javascript code that uses CPU
cycles or the DOM manipulations that cause the browser to recalculate the
layout and do other stuff all the time? If it's the browser then it doesn't
matter whether you use Javascript or webasm.

------
vkjv
Small correction

> cargo install wasm-bindgen

should be

> cargo install wasm-bindgen-cli

------
ealhad
Nice! I needed _exactly_ this.

------
pknopf
Does anybody know what debugging will look like here? Will LLDB work?

~~~
steveklabnik
Source maps do work today but nobody likes them. In general it’s a very
important thing to the WASM WG.

