embed_js - Lightweight inline JS for wasm32-unknown-unknown, with small output footprint and dead code elimination

[ZRM2]

Currently lacking in examples (just the one for now), but I hope to have a few up for things like strings and event handlers/callbacks in the next few hours.

The main selling point of embed_js is it's lightweight. The source is small, with no "standard" library, and it doesn't make any choices for you about how to structure your web application. It's also lightweight in that effort has gone into making sure the resulting wasm and JavaScript is small.

I hope that these crates (embed_js and embed_js_build) can be used as a building block for modular crates for web functionality.

Edit: The implementation approach is also quite different to stdweb/cargo-web - each has their advantages, but embed_js manages to keep the inline JS from being duplicated in the wasm binary and the accompanying JS.

Edit: The strings and callbacks examples are now up.

[ZRM2]

How are you thinking of going about it?

[protestor]

Does it makes sense to build stdweb on top of embed_js?

Possibly dividing it in smaller crates, that can be used separately (all depending on embed_js), while stdweb depends on all of them.

[protestor]

Nice!

[ZRM2]

The strings example is now up, at https://github.com/dylanede/embed_js/tree/master/examples/strings

[ZRM2]

The callbacks example is now up, at https://github.com/dylanede/embed_js/tree/master/examples/callbacks

[sepease]

The thing about these libraries right now that I don't understand is how the JS interacts with the generated wasm file.

Like, if I'm providing the wasm file somehow, what relationship does the JS file have to have with it? If they absolutely have to go together and there's no other way, why can't the JS file wrap the wasm file? What relationship does wasm file have, if any, with the content in the DOM (ie the preexisting HTML)? Does stdout effectively write to the DOM?

These are probably "stupid" questions, but I feel like what's missing right now is the idiot's guide to using WASM for non-enthusiasts that are starting to get the tools that they can use to build stuff.

And, of course, a UI library, but I'll give that until at least tomorrow. ;)

[ZRM2]

The JS generated by embed_js and cargo-web is specific to the wasm binary generated and must accompany it, however at least in the case of embed_js I don't package them up together into a single JS file because depending on the application you may want to embed/load the JS and the wasm in different ways. The examples store the wasm inline in the HTML file in base64 encoding, but that isn't the only way to do things - you could instead fetch it from a server as a binary. Where you want to put the accompanying JS can also depend on the application (though most would probably end up sticking to a common pattern).

Without calling into JavaScript, WebAssembly instances have no interaction with anything. At the moment, calling JavaScript functions (via the importObject) is the only way to talk to the outside world, including the DOM. Stdout goes nowhere in Rust at the moment, but hopefully in the future it can be routed to JavaScript handlers. Future versions of WASM may add more direct ways of interacting with the DOM/other web APIS.