Rust and WebAssembly

This Week in Rust and WebAssembly 15

2019-03-28T00:00:00+00:00

Hello and welcome to another issue of This Week in Rust and WebAssembly!

Rust is a systems language pursuing the trifecta: safety, concurrency, and speed.

WebAssembly is a stack-based virtual machine and instruction set. It is fast, safe, portable, and part of the open Web platform. By compiling to WebAssembly, we can run Rust code on the Web!

This is a weekly summary of Rust and WebAssembly’s progress and community.

Did we miss something? Tweet to us at @rustwasm or send us a pull request.

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

News and Blog Posts from Around the Web

Want to make sure something ends up on this list next time we publish an issue? Leave a comment on this issue.

Standardizing WASI: A system interface to run WebAssembly outside the web
- @alexcrichton already has a pull request to add a wasm32-unknown-wasi target for Rust!
RustVolley is a reimplementation of the Blobby Volley 2 game in Rust and Wasm
- Source
- Live Demo
CloudFlare’s new wrangler CLI tool lets you deploy Rust-generated Wasm on CloudFlare workers
Fastly open sources Lucet: a native WebAssembly compiler and runtime. Its built with Rust on top of Cranelift and supports WASI.

Updates from `rustwasm/*`

🎉 Welcome @Pauan to the Rust and WebAssembly working group core team! 🎉

RFCs

New RFCs

None.

Final Comment Period RFCs

Add an amendment to the RFC process

Merged RFCs

None.

Working Group Meetings

Gloo

Gloo Update: Onion Layers, Timers, and Events
@Aehmlo split up the gloo_timers crate’s public API to use callbacks and futures submodules, as we collectively agreed upon in other issues.
@cbrevik implemented the gloo_console_timer crate, which provides scoped closures and RAII-style helpers for working with console.time and console.timeEnd.
@OddCoincidence updated the gloo_timers internals to use wasm_bindgen::closures::Closure::once for setTimeout.
@RyLev added some initial Azure Pipelines continuous integration tests for Gloo.
@David-OConnor added the skeleton of an mdbook guide for Gloo.

`wasm-bindgen`

@alexcrichton tweaked the no-modules target’s generated JavaScript glue for instantiating Wasm modules to support CloudFlare workers (and other environments where x instanceof WebAssembly.Module might fail, like across <iframe>s)
@alexcrichton made it so that our emitted JS glue for reflecting Rust closures as JS functions will properly detect and protect against use-after-free from the JS side.
@alexcrichton fixed a bug where Rust structs exported as JS didn’t always emit the JS classes glue in a deterministic order.
@fitzgen made the “without a JS bundler” example use wasm-pack build --target web, now that its supported in the latest wasm-pack release.
@alexcrichton cleaned up the wasm-bindgen CLI’s options to take --target blah instead of --blah (which still exist but are deprecated).
@stevebob enabled mdbook’s link checking tests for the wasm-bindgen guide to our continuous integration tests.
@alexcrichton implemented rustwasm/rfcs#8 to enable transitive crates dependencies on npm packages.
@RReverser added the constructor property to js_sys::Object.
@alexcrichton fixed sending large u32s from Wasm to JS.
@RReverser consistently exposed is_like_none for our generated JS glue, fixing a bug along the way.
@RReverser simplified the ABI representation of Option<char>.
@alexcrichton migrated all the wasm-bindgen-* crates to Rust 2018 edition.
@RReverser made iterating over JS objects via the JS iteration protocol faster by removing redundant property string decoding.
@RReverser made a special version of passing strings from JS to Wasm when we are targeting Node.js that is faster than using Node.js’s TextEncoder implementation.

`wasm-pack`

@alexcrichton fixed a panic that could happen when installing the wasm-bindgen CLI tool.

Requests for Contribution

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

New Good First Issues

New “Help Wanted” Issues

wasm-bindgen: Closures should accept references as arguments

Gloo Update: Onion Layers, Timers, and Events

2019-03-26T00:00:00+00:00

About two weeks ago, we kicked off our effort to collectively build Gloo, a modular toolkit for building fast and reliable Web apps and libraries with Rust and Wasm. We knew we wanted to explicitly cultivate the Rust and Wasm library ecosystem by spinning out reusable, standalone libraries: things that would help you out whether you were writing a green-field Web app in pure-Rust, building your own framework, or surgically inserting some Rust-generated Wasm into an existing JavaScript project. What was still fuzzy, and which we didn’t know yet, was how we were going design and expose these reusable bits.

Onion-Layered APIs

I’m pleased to tell you that that after some collaborative discussion in issue threads, we’ve come up with a promising approach to designing Gloo APIs, and we’ve since formalized it a bit in CONTRIBUTING.md. I’ve nicknamed this approach “onion-layered” API design.

Briefly, we want to build mid-level abstraction libraries on top of raw -sys bindings, build futures and streams integration on top of the mid-level APIs, and build high-level APIs on top of all that. But — crucially — every layer should be publicly exposed and reusable.

While this approach to API design is certainly not novel, we want to very deliberately follow it so that we

maximize reusability for the larger ecosystem, and
exercise our mid-level APIs when building higher-level APIs, to ensure their generality and suitability for acting as a solid foundation.

As we go through and examine each layer, I’ll use the setTimeout and setInterval Web APIs as a running example.

The Core: `wasm-bindgen`, `js-sys`, and `web-sys`

The innermost layer are raw bindings built on top of wasm-bindgen, js-sys and web-sys. These bindings are fast, have a light code size foot print, and are future-compatible with the host bindings proposal.

What they are not is super ergonomic to use all of the time. Using raw web-sys bindings directly can sometimes feel like making raw libc calls instead of leveraging Rust’s nice std abstractions.

Here is doing some operation after a 500 millisecond timeout using raw web-sys bindings:

use wasm_bindgen::{closure::Closure, JsCast};

// Create a Rust `FnOnce` closure that is exposed to JavaScript.
let closure = Closure::once(move || {
    do_some_operation();
});

// Get the JavaScript function that reflects our Rust closure.
let js_val = closure.as_ref();
let js_func = js_val.unchecked_ref::<js_sys::Function>();

// Finally, call the `window.setTimeout` API.
let timeout_id = web_sys::window()
    .expect("should have a `window`")
    .set_timeout_with_callback_and_timeout_and_arguments_0(js_func, 500)
    .expect("should set a timeout OK");

// Then, if we ever decide we want to cancel the timeout, we do this:
web_sys::window()
    .expect("should have a `window`")
    .clear_timeout_with_handle(timeout_id);

The `callbacks` Layer

When we look at the raw web-sys usage, there is a bit of type conversion noise, some unfortunate method names, and a handful of unwraps for ignoring edge-case scenarios where we prefer to fail loudly rather than limp along. We can clean all these things up with the first of our “mid-level” API layers, which in the case of timers is the callbacks module in the gloo_timers crate (which is also re-exported from the gloo umbrella crate as gloo::timers).

The first “mid-level” API built on top of the -sys bindings exposes all the same functionality and the same design that the Web does, but uses proper Rust types. For example, at this layer, instead of taking untyped JavaScript functions with js_sys::Function, we take any F: FnOnce(). This layer is essentially the least opinionated direct API translation to Rust.

use gloo::timers::callbacks::Timeout;
// Alternatively, we could use the `gloo_timers` crate without the rest of Gloo:
// use gloo_timers::callbacks::Timeout;

// Already, much nicer!
let timeout = Timeout::new(500, move || {
    do_some_operation();
});

// If we ever decide we want to cancel our delayed operation, all we do is drop
// the `timeout` now:
drop(timeout);

// Or if we never want to cancel, we can use `forget`:
timeout.forget();

Layering on Futures and Streams

The next layer to add is integrating with popular traits and libraries in the Rust ecosystem, like Futures or serde. For our running gloo::timers example, this means we implement a Future backed by setTimeout, and a Stream implementation backed by setInterval.

use futures::prelude::*;
use gloo::timers::futures::TimeoutFuture;

// By using futures, we can use all the future combinator methods to build up a
// description of some asynchronous task.
let my_future = TimeoutFuture::new(500)
    .and_then(|_| {
        // Do some operation after 500 milliseconds...
        do_some_operation();

        // and then wait another 500 milliseconds...
        TimeoutFuture::new(500)
    })
    .map(|_| {
        // after which we do another operation!
        do_another_operation();
    })
    .map_err(|err| {
        handle_error(err);
    });

// Spawn our future to run it!
wasm_bindgen_futures::spawn_local(my_future);

Note that we use futures 0.1 for now, because we’ve fought tooth and nail to get the Wasm ecosystem on stable Rust, but as soon as the new std::future::Future design is stable, we plan to switch over. We are very excited for async/await as well!

More Layers?

That’s all the layers we have for the setTimeout and setInterval APIs. Different Web APIs will have different sets of layers, and this is fine. Not every Web API uses callbacks, so it doesn’t make sense to always have a callbacks module in every Gloo crate. The important part is that we are actively identifying layers, making them public and reusable, and building higher-level layers on top of lower-level layers.

We will likely add even higher-level layers to other Web APIs where it makes sense. For example, the File API’s FileReader interface exposes methods that you shouldn’t call until after certain events have fired, and any attempt to call them earlier will throw. We can codify this as a state machine-based Future, that doesn’t even give you the ability to call those methods until after the relevant events have fired and the state machine reaches a certain state. Leveraging types at compile time for ergonomics and correctness!

Another future direction is adding more integration layers with more parts of the larger Rust crates ecosystem. For example, adding functional reactive programming-style layers via the futures-signals crate which is also used by the dominator framework.

Events

One of the active bits of design work going on in Gloo right now is how to craft our event targets and listeners layer. Events are used across most of the Web APIs, so it is very important we get this design right, as it will sit underneath many of our other crates. While we haven’t 100% nailed down the design yet, I really like where we are headed.

On top of web_sys::Event and web_sys::EventTarget::add_event_listener_with_callback, we are building a layer for adding and removing event listeners and managing their lifetimes from Rust via RAII-style automatic cleanup upon drop.

We can use this API to make idiomatic Rust types that attach event listeners that automatically get removed from the DOM when the type is dropped:

use futures::sync::oneshot;
use gloo::events::EventListener;

// A prompt for the user.
pub struct Prompt {
    receiver: oneshot::Receiver<String>,

    // Automatically removed from the DOM on drop!
    listener: EventListener,
}

impl Prompt {
    pub fn new() -> Prompt {
        // Create an `<input>` to prompt the user for something and attach it to the DOM.
        let input: web_sys::HtmlInputElement = unimplemented!();

        // Create a oneshot channel for sending/receiving the user's input.
        let (sender, receiver) = oneshot::channel();

        // Attach an event listener to the input element.
        let listener = EventListener::new(&input, "input", move |_event: &web_sys::Event| {
            // Get the input element's value.
            let value = input.value();

            // Send the input value over the oneshot channel.
            sender.send(value)
                .expect_throw(
                    "receiver should not be dropped without first removing DOM listener"
                );
        });

        Prompt {
            receiver,
            listener,
        }
    }
}

// A `Prompt` is also a future, that resolves after the user input!
impl Future for Prompt {
    type Item = String;
    type Error = ();

    fn poll(&mut self) -> Poll<Self::Item, Self::Error> {
        self.receiver
            .poll()
            .map_err(|_| {
                unreachable!(
                    "we don't drop the sender without either sending a value or dropping the whole Prompt"
                )
            })
    }
}

On top of that layer, we are using Rust’s trait system to design a higher-level, static events API that will make the events casting safe and statically-checked, and make sure you don’t have typos in the event types that you listen to:

use gloo::events::{ClickEvent, on};

// Get an event target from somewhere.
let target: web_sys::EventTarget = unimplemented!();

// Listen to the "click" event, know that you didn't misspell the event as
// "clik", and also get a nicer event type!
let click_listener = on(&target, move |e: &ClickEvent| {
    // The `ClickEvent` type has nice getters for the `MouseEvent` that
    // `"click"` events are guaranteed to yield. No need to dynamically cast
    // an `Event` to a `MouseEvent`.
    let (x, y) = event.mouse_position();

    // ...
});

These event APIs are still works in progress and have some kinks to work out, but I’m very excited for them, and we hope to get a lot of mileage out of them as we build other Gloo crates that internally use them.

Get Involved!

Let’s build Gloo together! Want to get involved?

This Week in Rust and WebAssembly 14

2019-03-21T00:00:00+00:00

Hello and welcome to another issue of This Week in Rust and WebAssembly!

Rust is a systems language pursuing the trifecta: safety, concurrency, and speed.

WebAssembly is a stack-based virtual machine and instruction set. It is fast, safe, portable, and part of the open Web platform. By compiling to WebAssembly, we can run Rust code on the Web!

This is a weekly summary of Rust and WebAssembly’s progress and community.

Did we miss something? Tweet to us at @rustwasm or send us a pull request.

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

News and Blog Posts from Around the Web

Want to make sure something ends up on this list next time we publish an issue? Leave a comment on this issue.

Updates from `rustwasm/*`

RFCs

New RFCs

Add watch and serve subcommands to wasm-pack

Final Comment Period RFCs

None.

Merged RFCs

Working Group Meetings

Gloo

Gloo is the modular toolkit we decided to collectively build in our 2019 roadmap. We’ve been having lots of good discussion about scope and API design in issue threads! (Not doing lots of PRs quite yet.)
@OddCoincidence added support for setInterval to gloo-timers.

`rustwasm.github.io`

@DebugSteven removed some unused CSS rules from our Website’s stylesheets.

`rust-webpack-template`

@alexcrichton upgraded the template to the Rust 2018 edition.

Twiggy

@data-pup upgraded Twiggy to the Rust 2018 edition.
@data-pup added more tests for the twiggy diff subcommand.

`wasm-bindgen`

We released wasm-bindgen version 0.2.39! 🎉
@c410-f3r made wasm-bindgen’s generated TypeScript interfaces’ functions’ argument names be preserved from the Rust source instead of being generated symbols.
@ibaryshnikov cleaned up our Web GL example.
@nstoddard added immutability whitelisting for Uint8Array, ArrayBufferView, and BufferSource.
@RReverser fixed some copy-paste errors in documentation for Int32Array and Uint32Array
@RReverser cleaned up and de-duplicated our binding definitions to the different kinds of typed arrays!
@c410-f3r expanded the testing of our emitted TypeScript interface definitions.
@alexcrichton added the #[wasm_bindgen(raw_module = "...")] attribute to the wasm-bindgen proc-macro.
@konradsz fixed the number-slices example’s JS imports.
@alexlapa enabled passing optional imported enums over the FFI boundary.

`wasm-pack`

We released wasm-pack version 0.7.0! 🎉
@alexcrichton added support for the web target to wasm-pack. This target uses browsers’ native support for ES modules, and doesn’t require the use of a JS bundler.
@alexcrichton started migrating wasm-pack’s CLI output towards our 1.0 vision for wasm-pack output. Notably, cargo build’s colors and progress bar should work now.
@alexcrichton added a smorgasbord of docs improvements.
@drager added support for non-rustup-based Rust development environments to wasm-pack.
@ashleygwilliams added a quickstart doc page for using wasm-pack with Webpack.

`wasm-pack-template`

@alexcrichton upgraded the template to the Rust 2018 edition.

Requests for Contribution

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

New Good First Issues

Gloo: Make the timers crate follow submodule design

Let’s Build Gloo Together

2019-03-12T00:00:00+00:00

The Rust and WebAssembly domain working group wants to cultivate a stable, batteries-available, and production-ready ecosystem for Rust and Wasm development in 2019.

To further that goal, we are creating Gloo, a modular toolkit for building both:

small, targeted Wasm modules that integrate into a larger JavaScript system, and
whole Web applications written in Rust.

Gloo’s goals for Wasm are similar to what the Async Ecosystem working group’s Tide project intends to do for server-side Web development:

The name “Tide” refers to “a rising tide lifts all boats”; the intent is to improve sharing, compatibility, and improvements across all web development and frameworks in Rust.

The Utility High-Level Libraries and Frameworks Provide

We use high-level libraries and frameworks instead of using Web APIs directly because we want abstractions with which we can naturally express ourselves. We outsource non-business logic concerns so that we can create more robust libraries and applications more quickly than we otherwise would. For example, the desires people might have include:

They prefer describing how they want the DOM to look like right now, rather than enumerating a list of modifications that will transform its current state into their desired state. Therefore, they use an immediate-mode virtual DOM library.
They prefer thinking in terms of Rust types, not about the raw, serialized bytes in a fetched HTTP response body or about object stores in Indexed DB. Therefore, they use derive-based serialization and deserialization with serde.

There are many different ways to approach high-level APIs, and people have lots of differing opinions about which way is best! Designing these APIs well is difficult: we have correctness, ergonomic, and performance concerns.

How Gloo Fits In

Gloo aims to be both a collection of small, focused utility crates and an umbrella crate that pulls all the utilities together into a single package.

Our goals with Gloo are:

To bolster the Rust and WebAssembly crates ecosystem. Pick and choose utility crates even if you aren’t using the whole umbrella Gloo crate, or if you are using some other Rust and Wasm framework. We have some crates like this today — for example the console_log crate — but we would like to intentionally grow more shared utility crates across the ecosystem.
To wrap these utilities up in an umbrella crate so that your new project can hit the ground running. This umbrella crate will be a thin wrapper around the utility crates, and provides defaults wherever multiple (perhaps opinionated) choices exist. To keep the umbrella crate small, we should be constantly pulling code out into new shared, utility crates. For the more opinionated bits, like virtual DOM rendering or web components, the umbrella crate should prefer interfaces over implementations, so that different implementations with different approaches are swap-able.

Gloo is far from ready right now! The project has only just begun. But we want to build Gloo as a collective and in an open way, so we are announcing it early and inviting you to come help us design and build it.

Want to get involved?

Where We’re Starting

At the 2019 Rust All Hands meeting in Berlin, we found that it was useful to categorize Web libraries by whether they were opinionated or not. We all want idiomatic-Rust wrapper crates around raw web-sys timers and requestAnimationFrame etc, and there isn’t a whole lot of design work that needs to happen for this. For many of these kinds of crates, we are ready to dive into implementation. On the other hand, for the more opinionated bits, like virtual DOMs and state management, we need to do exploratory design work before committing to a particular approach.

We’ll start exploring the design space of the latter group in a series of follow up blog posts. In the meantime, if you want to get involved, start hacking on some of the utility crates, or brainstorm about designs, then check out some of the issues on Gloo’s GitHub repository.

This Week in Rust and WebAssembly 13

2019-03-07T00:00:00+00:00

Hello and welcome to another issue of This Week in Rust and WebAssembly!

Rust is a systems language pursuing the trifecta: safety, concurrency, and speed.

WebAssembly is a stack-based virtual machine and instruction set. It is fast, safe, portable, and part of the open Web platform. By compiling to WebAssembly, we can run Rust code on the Web!

This is a weekly summary of Rust and WebAssembly’s progress and community.

Did we miss something? Tweet to us at @rustwasm or send us a pull request.

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

News and Blog Posts from Around the Web

Want to make sure something ends up on this list next time we publish an issue? Leave a comment on this issue.

Up and Running with React, Rust, and Wasm
The Tao of Rust is a book about Rust that was originally published in China. It has a WebAssembly section, and is getting translated into English!
Tweek is a new tween animation kit for Rust that supports Wasm

Updates from `rustwasm/*`

RFCs

New RFCs

Amend the RFC process

Final Comment Period RFCs

None.

Merged RFCs

Add support for local JavaScript snippets to wasm-bindgen

Working Group Meetings

`rustwasm.github.io`

@DebugSteven and @alexcrichton aggregated the Rust and WebAssembly book, the wasm-bindgen guide, and the wasm-pack guide into a single bookshelf, where all of our docs can be found in one place!

`twiggy`

@data-pup added rustfmt and clippy integration into Twiggy’s CI setup.
@sepiropht improved Twiggy’s detection of what kind of binary it is looking at when there is no file extension.

`walrus`

@data-pup fixed the wasm round-tripping tests for the latest release of the webassembly/wabt tools.
@alexcrichton added support for the WebAssembly SIMD proposal to walrus.

`wasm-bindgen`

@fitzgen added support for FnOnce functions to wasm_bindgen::Closure.
@c410-f3r fixed wasm-bindgen compilation when the "extra-traits" feature was enabled.
@alexcrichton implemented the local JavaScript snippets RFC for wasm-bindgen.
@Vlad-Scherbina fixed a bug where if the directory specified by --out-dir does not exist, then running the wasm-bindgen CLI would fail.
@alexcrichton added testing of wasm-bindgen’s generated TypeScript interface definition files in CI.

`wasm-pack`

@drager wrote a test suite for wasm-pack’s binary installation utility crate.

Requests for Contribution

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

This Week in Rust and WebAssembly 12

2019-02-28T00:00:00+00:00

Hello and welcome to another issue of This Week in Rust and WebAssembly!

Rust is a systems language pursuing the trifecta: safety, concurrency, and speed.

WebAssembly is a stack-based virtual machine and instruction set. It is fast, safe, portable, and part of the open Web platform. By compiling to WebAssembly, we can run Rust code on the Web!

This is a weekly summary of Rust and WebAssembly’s progress and community.

Did we miss something? Tweet to us at @rustwasm or send us a pull request.

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

News and Blog Posts from Around the Web

Want to make sure something ends up on this list next time we publish an issue? Leave a comment on this issue.

Replacing a hot path in your app’s JavaScript with WebAssembly. The article compares versions written in Rust, C/C++, and AssemblyScript.
Was (not Wasm) is a hostile allocator for AssemblyScript that is written in Rust.
Wasmer has improved their startup time by 100x.
WebAssembly Troubles part 4: Microwasm. The culmination of a series of posts about issues the author has with WebAssembly, along with proposals for how to fix them.
Generating snow with Rust and Wasm
- Live demo
- Source

Updates from `rustwasm/*`

RFCs

New RFCs

None.

Final Comment Period RFCs

Add support for local JavaScript snippets in wasm-bindgen

Merged RFCs

None.

Working Group Meetings

`rustwasm/rust-parcel-template`

@tock203 fixed a ReferenceError in the template’s initialization code.

`rustwasm/twiggy`

@data-pup set up rustfmt-checking for our continuous integration.
@alexcrichton made Twiggy account for header and section size bytes of a Wasm binary, so Twiggy’s output should sum to 100% now instead of just short of that.
@philipc updated Twiggy to version 0.17.0 of gimli, the crate it uses to parse DWARF debugging information.
@alexcrichton switched Twiggy over to using the wasmparser crate to parse Wasm binaries, which gives more precise byte offset and size information, and is faster than the old Wasm parser.
@data-pup added an unreachable items summary to the twiggy dominators output, so that all top-level rows’ sizes will sum to 100%.

`rustwasm/wasm-bindgen`

@tyleranton added support for emitting doc comments in the TypeScript interface definition files that wasm-bindgen creates.
@LegNeato fixed the wasm-bindgen-test headless browser test runner on macOS High Sierra.
@alexcrichton updated the wasm-bindgen guide and added a “Deployment” section.
@alexcrichton added support for the new TextEncoder.prototype.encodeInto method to wasm-bindgen’s generated JS glue when passing strings between wasm and JS.

`rustwasm/wasm-pack`

@ashleygwilliams removed unnecessary entries from the "files" key in wasm-pack’s generated package.json.
@ashleygwilliams fixed the [wasm-pack] installer on windows when it is downloaded multiple times and ends up with a (1) suffix in its filename.
@surma wrote some docs on the wee_alloc integration for the wasm-pack template.
@DebugSteven wrote a series of get-started-in-X-environment tutorials for wasm-pack.

Requests for Contribution

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

New Good First Issues

wasm-bindgen: Add #[wasm_bindgen(ignore)] to ignore a pub field and not generate getters/setters for it

This Week in Rust and WebAssembly 11

2019-02-21T00:00:00+00:00

Hello and welcome to another issue of This Week in Rust and WebAssembly!

Rust is a systems language pursuing the trifecta: safety, concurrency, and speed.

WebAssembly is a stack-based virtual machine and instruction set. It is fast, safe, portable, and part of the open Web platform. By compiling to WebAssembly, we can run Rust code on the Web!

This is a weekly summary of Rust and WebAssembly’s progress and community.

Did we miss something? Tweet to us at @rustwasm or send us a pull request.

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

News and Blog Posts from Around the Web

Want to make sure something ends up on this list next time we publish an issue? Leave a comment on this issue.

Parsing and rendering PSD files in the browser with Rust and WebAssembly
Programmatically generating Islamic stars using the “Polygons in Contact” method with Rust-generated Wasm and Web GL
- Live demo
- Source
Dust is a renderer written in Rust that has a backend for Wasm and Web GL
- Live demo
- Source

Updates from `rustwasm/*`

RFCs

New RFCs

None.

Merged RFCs

None.

`console_error_panic_hook`

@fitzgen added error stacks to the message we log when a panic occurs. This works around bugs in both Safari’s and Firefox’s developer tools consoles.

`js-sys`

@Pauan added convenience getters to js_sys::Reflect for getting properties keyed by u32 and f64.

Twiggy🌱

@data-pup fixed some unused-result warnings in Twiggy’s parser.

`walrus`

@alexcrichton made GC’ing unused functions, globals, etc an explicit pass in walrus. It was previously performed implicitly as part of serializing a wasm module.
@alexcrichton implemented support for the reference types proposal and anyref in walrus.
@fitzgen added the ability to explicitly delete various wasm constructs (functions, tables, etc) from a wasm module, rather than just implicitly delete them by making them unused and then running a GC.

`wasm-bindgen`

@alexcrichton added support for Option<MyRustStruct> in parameters and return positions.
@alexcrichton added experimental support for using anyref in wasm-bindgen.
@fitzgen fixed a regression where DWARF debug info custom sections were always being included in the generated Wasm, even when debug info was not enabled.
@alexcrichton added a flag to control whether the producers custom section is included in the generated wasm binary or not.
@ctjhoa fixed some deprecation warnings around the use of ATOMICS_*_INIT instead of Atomic*::new.

`wasm-snip`

@fitzgen ported wasm-snip over to using the walrus crate. This also removes the need to wasm-gc again after running wasm-snip.

`web-sys`

@selaux added a missing Web IDL attribute to HTMLMediaElement so that web-sys correctly generates bindings to the srcObject property.

`wee_alloc`

We released wee_alloc version 0.4.3! 🎉 Among other things, this version will work on stable Rust as soon as 1.33 is released, which is scheduled for one week from today: 2019-02-28.

Requests for Contribution

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

New Good First Issues

This Week in Rust and WebAssembly 10

2019-02-13T00:00:00+00:00

Hello and welcome to another issue of This Week in Rust and WebAssembly!

Rust is a systems language pursuing the trifecta: safety, concurrency, and speed.

WebAssembly is a stack-based virtual machine and instruction set. It is fast, safe, portable, and part of the open Web platform. By compiling to WebAssembly, we can run Rust code on the Web!

This is a weekly summary of Rust and WebAssembly’s progress and community.

Did we miss something? Tweet to us at @rustwasm or send us a pull request.

News and Blog Posts from Around the Web

Want to make sure something ends up on this list next time we publish an issue? Leave a comment on this issue.

Reflecting on Rust and WebAssembly in 2018
wasm-bindgen — how does it work?!
Edge programming with Rust and WebAssembly with Terrarium
Embedding WebAssembly in your Rust Application with wasmer.io
The console_log crate is a backend for the log facade that pipes logged messages to the browser’s console.
Zemeroth is a turn-based hexagonal tactical game written in Rust and WebAssembly.
An example implementation of react/redux style UI development in Rust with percy
Seed is a new Wasm framework for Web apps.
sendilkumarn/generator-wasm-app is a a Wasm app generator for Yeoman.
edvorg/rustsmith is a Rocksmith clone for the Web platform built with Rust and WebAssembly.

`#RustWasm2019` Posts

Rust WebAssembly 2019 by Ryan Levick
My Rust 2019 Dream: Dominate the Web by richardanaya
Wasm 2019 by Yoshua Wuyts
Rust and WebAssembly in 2019 by Nick Fitzgerald
Non-Web Embeddings for Rust Wasm 2019 by Brandon Fish and wasmer.io

Wasm at the 2019 Rust All Hands

The 2019 Rust All Hands meetup was in Berlin on February 4^th through 8^th. @ag_dubs, @alexcrichton, @fitzgen, and @yoshuawuyts from the Rust and WebAssembly working group all made it out to discuss some Wasm-related topics and plan for 2019.

We talked about:

The road to wasm-pack 1.0. This meeting was about trying to pin down what we want to ship as part of a wasm-pack 1.0 release, as well as crystallize wasm-pack’s ideal UX.
A modular toolkit for Wasm. There’s been a lot of talk in #RustWasm2019 posts and the 2019 roadmap RFC about building a modular toolkit for Wasm apps and libraries. This meeting was trying to dig a bit more into the details of what that entails. And naming, of course.
cargo build tasks, hooks, and/or post-build.rs for Wasm. Long-term (likely on the timeline of a couple years) we would like the experience of building Rust and Wasm projects to be exactly the same as building normal Rust projects: just cargo build and that’s it. But there is a bunch of stuff that needs to happen for Wasm after rustc emits a Wasm binary, such as generate JS bindings or run wasm-opt. This meeting was about how to add some sort of generic build hooks to cargo and turn wasm-pack into an implementation of those generic hooks specifically targeted for Wasm development.
Multithreading Wasm and rayon. This meeting was about how we take our experimental Wasm multithreading support and turn it into a reliable library that can serve as the foundation for multithreading on the Web. @CUViper from the rayon team also joined, and we made a plan for how to get rayon working in Wasm.

Updates from `rustwasm/*`

RFCs

New RFCs

2019 Roadmap — this is your chance to help shape our goals for the year!
Add support for local JS snippets in wasm-bindgen

Merged RFCs

None.

Book

@DebugSteven wrote a testing section for the Game of Life tutorial!

Twiggy🌱

We released Twiggy🌱 0.4.0! 🎉
@brson fixed a bug where we would attempt to demangle things that were not C++ symbols as if they were C++ symbols.

`walrus`

walrus is a new library crate for writing Wasm-to-Wasm transformations. It will eventually (but doesn’t yet) preserve DWARF debug info for the Wasm across your transformations.
@alexcrichton got walrus round-tripping all the Wasm spec tests correctly.
@fitzgen wrote a simple Wasm fuzzer, immediately found a bug, and whipped up a fix.
@alexcrichton refactored instruction parsing to avoid recursion. This means that we don’t blow the stack in debug builds or when given malicious input.
We just released walrus 0.1.0 on crates.io — expect more exciting things from walrus in the future :)

`wasm-bindgen`

We released wasm-bindgen 0.2.29 through 0.2.36! 🎉
@derekdreery improved the std::fmt::Debug output for JsValue so that it includes object properties and their values, instead of just [object Object].
@fitzgen made the wasm-bindgen-test testing infrastructure capture more console logging methods’ (warn, info, etc) output for displaying in stdout.
@T5uku5hi added #[allow(clippy::all)] to wasm-bindgen’s macro-generated code, so that running clippy on crates that use wasm-bindgen isn’t so noisy.
@alexcrichton added support for passing Option<MyEnum> back and forth between Wasm and JS if MyEnum has the #[wasm_bindgen] attribute.
@fitzgen added the UnwrapThrowExt trait to wasm-bindgen’s prelude. This extension trait adds unwrap_throw and expect_throw methods to Option<T> and Result<T, E> that have the same behavior as regular unwrap and expect except they throw a JS error on failure instead of panicking. This is morally the same, but ends up avoiding the std::panicking and std::fmt infrastructure, resulting in smaller code sizes.
@alexcrichton migrated wasm-bindgen’s post-rustc Wasm transformations to the new walrus crate! This paves the way for maintaining DWARF debug info through wasm-bindgen.
@fitzgen made the wasm-bindgen-test runtime capture logged messages in tests via textContent instead of innerHTML, avoiding issues when logging HTML strings ;)

`wasm-pack`

We released wasm-pack 0.6.0! 🎉
@drager implemented support for typo detection in wasm-pack’s Cargo.toml section.
@torkve added support for passing arbitrary extra CLI arguments through wasm-pack build and into cargo build. For example, to build with all cargo features enabled: wasm-pack build -- --all-features.
This inspired @chinedufn to add support for passing arbitrary extra CLI arguments through wasm-pack test and into cargo test!
@fitzgen fixed a bug where the output of wasm-pack test was printed twice.
@rhysd added support for emitting the “homepage” field in our generated package.json if it is present in the crate’s Cargo.toml.
@jscheffner fixed wasm-pack’s fetching of chromedriver binaries for headless browser testing on Windows.

Requests for Contribution

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

New “Help Wanted” Issues

Reflecting on Rust and WebAssembly in 2018

2018-12-06T00:00:00+00:00

🎉 The 2018 edition of Rust has officially shipped, and the initial Rust and WebAssembly development story along with it! 🎉

To see how far we’ve come, let’s reflect on the Rust and WebAssembly story a year ago: rustc could emit WebAssembly binaries for you, but that was about it. As far as communication with JavaScript went, you had to work with raw wasm imports and exports yourself. That meant you could only pass 32- and 64-bit integers and floats back and forth. No Rust structs, JavaScript objects, strings, or slices could be passed back forth. And distributing your library’s .wasm so that other downstream projects could depend on it? Good luck.

While it was clear there was huge potential for Rust and WebAssembly, no one was sure what exactly that meant. So when the Rust and WebAssembly domain working group formed, we rallied around making this shared vision into a reality:

Compiling Rust to WebAssembly should be the best choice for fast, reliable code for the Web.

As our ideas evolved, we distilled another core value:

Rust and WebAssembly is here to augment your JavaScript, not replace it.

The same way that Rust integrates with C libraries and calling conventions on native targets, it should play nice with JavaScript and HTML5 APIs on the Web. You should not have to rewrite your whole Web application or JavaScript library. We cannot realize our vision for Rust and wasm if it means you have to start over from scratch; it wouldn’t be practical.

Given these shared values and vision, we set out goals for what we wanted the Rust and WebAssembly ecosystem, toolchain, and workflow to look like by the time Rust 2018 shipped.

Goal: ☑ Zero-Cost JavaScript Interoperation

Rust enables fast and expressive code by leveraging zero-cost abstractions. We wanted to apply this principle to our whole JS interop infrastructure. Yes, you can write your own boilerplate to pass DOM nodes to Rust-generated wasm, but you shouldn’t have to, and the provided infrastructure should be as fast as if you did hand-code it. If you call IndexedDB APIs, that shouldn’t bloat your .wasm binary with unused bindings to Web GL functions.

We created wasm-bindgen as the foundation for zero-cost JavaScript interoperation. wasm-bindgen facillitates communication between JavaScript and WebAssembly, and generates glue code that you would otherwise have to write yourself. On top of wasm-bindgen, we built js-sys (raw bindings to ECMAScript APIs) and web-sys (raw bindings to Web APIs).

Using the wasm-bindgen ecosystem, we can easily and performantly

export rich APIs from our Rust-generated wasm libraries, so they are callable from JavaScript, and
import JavaScript and Web APIs into our Rust-generated wasm.

All in a zero-cost manner.

Additionally, wasm-bindgen is forward-compatible with the WebAssembly host bindings proposal. Host bindings will remove the tiny, generated JavaScript shim functions that sit between our wasm functions and DOM methods. Eventually, host bindings promises to unlock even-faster-than-JavaScript DOM access since calls can be statically validated once rather than dynamically checked every time.

Goal: ☑ Distributing Rust-Generated Wasm as an NPM Library

Superb integration isn’t only about exporting and importing functionality between Rust-generated WebAssembly and JavaScript. It is also fitting into the JavaScript’s distribution mechanisms, and a big chunk of that story is NPM.

We built wasm-pack to make it easy to create and publish NPM packages from your Rust and WebAssembly code. There didn’t used to be any story whatsoever for sharing Rust-generated wasm modules. Now, all it takes is:

wasm-pack publish

Goal: ☑ Get Developers Productive Fast

We wrote a Rust and WebAssembly book that teaches you all the ins and outs of WebAssembly development with Rust. It features a tutorial where you build an implementation of Conway’s Game of Life, and then you learn to write tests for headless browsers, debug wasm code when things go wrong, and how to diagnose slow code paths and then speed them up.

We realized that there are a bunch of “post-build” tools you want to run after cargo and rustc emit the initial .wasm binary. For usability and developer productivity, we expanded wasm-pack’s role from creating and publishing NPM packages to orchestrating all of these tasks. wasm-pack will manage your wasm-bindgen CLI binaries and install browsers’ WebDriver clients for you automatically.

For example, want to run tests in a headless Firefox browser? Just run

wasm-pack test --headless --firefox

No need to pull your hair out trying to install and configure anything!

Finally, we recognized that getting your Rust and WebAssembly project set up initially involves a bit of boilerplate and configuration that new users aren’t prepared for and experienced users don’t want to waste time on. So we created a variety of project templates for different use cases, so you can hit the ground running:

wasm-pack-template for creating NPM libraries with Rust and Wasm.
create-wasm-app for creating Web applications built on top of Rust-generated wasm NPM libraries.
rust-webpack-template for creating whole Web applications with Rust, WebAssembly, and the Webpack bundler.
rust-parcel-template for creating whole Web applications with Rust, WebAssembly, and the Parcel bundler.

Goal: ☑ Rust-Generated Wasm Should be Testable and Debuggable

We recognized that testing and debugging infrastructure are table stakes for creating reliable code and developer productivity.

By default, wasm can’t log any panics or errors because it doesn’t have any “syscall” or I/O functionality. You have to add imports for that sort of thing yourself, and then instantiate the module with the appropriate functions. To remedy this problem, and to ensure that panics are always debuggable, we created the console_error_panic_hook crate, which redirects panic messages into the browser’s devtools console.

While you can always run normal #[test]s on the native target for portable, platform-agnostic code, that isn’t sufficient for testing your library’s interaction with the DOM, asynchronous JavaScript promises, or event handlers. So we created the wasm-bindgen-test infrastructure, and made installing and configuring the necessary binaries for headless browser and Node.js testing a breeze with wasm-pack test.

We also had experienced that diagnosing where code size was coming from could be hard with WebAssembly. We wanted to know things like which function was calling another function, and causing it to be included in the .wasm binary, so we created the Twiggy🌱 code size profiler for WebAssembly.

 Shallow Bytes │ Shallow % │ Retaining Paths
───────────────┼───────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
           152 ┊     5.40% ┊ wee_alloc::alloc_with_refill::hb32c1bbce9ebda8e
               ┊           ┊   ⬑ func[2]
               ┊           ┊       ⬑ <wee_alloc::size_classes::SizeClassAllocPolicy<'a> as wee_alloc::AllocPolicy>::new_cell_for_free_list::h3987e3054b8224e6
               ┊           ┊           ⬑ func[5]
               ┊           ┊               ⬑ elem[0]
               ┊           ┊       ⬑ hello
               ┊           ┊           ⬑ func[8]
               ┊           ┊               ⬑ export "hello"

#RustWasm2019

All of our goals have been focused on things we could deliver in tandem with the 2018 edition. But now that the 2018 edition has shipped, it is time to think about what we want to achieve in 2019 and beyond.

This is where you come in!

Following in the larger Rust project’s tradition, we’re asking the community to write blog posts reflecting on Rust and WebAssembly in 2018 and proposing goals and directions for Rust and WebAssembly in 2019. We’ll read everything, and then propose an RFC for the Rust and WebAssembly domain working group’s roadmap in 2019.

Write down your thoughts on whatever your writing platform of choice is. It could be:

Your personal or company blog
A GitHub gist
A Medium post
Any other platform you prefer

We’re looking for posts on many different topics:

Ideas for community programs
Tooling enhancements
Ecosystem and library needs
Documentation improvements
Anything else related to Rust and Wasm!

Tweet your write up with the #RustWasm2019 hashtag or drop a link on this github issue. We’ll aggregate everything everyone has written in another big post on this blog. Then, the core Rust and WebAssembly working group team will read over all of them and write up an RFC for the working group’s 2019 roadmap! This RFC will follow our normal RFC process and everyone will have a chance to discuss it, improve it, and help polish it.

Preliminary Timeline

Now through January 15^th: Share your #RustWasm2019 post, read posts by others, discuss them, bounce ideas back and forth.
End of January: We’ll formally propose the 2019 roadmap RFC, and then work it through the RFC process together as a community.
End of February: We’re aiming for having consensus on the 2019 roadmap and merging the RFC before the end of February.

Thank You for a Wonderful 2018! 💖

Thanks to everyone who contributed to Rust and WebAssembly in 2018! (Apologies if we missed anyone in this list!)

0xazure
Aaron Turon
Aditya Arora
Aidan Hobson Sayers
Aleksey Kladov
Alex Crichton
Alex Macleod
Alexander Kryvomaz
Alfie John
Anders Pitman
Andrew Champion
Andrew Chin
Andy Bell
Anna Bogus
Anton Danilkin
Ashley Williams
Ben Merritt
Benjamin Kampmann
Blixt
Bradlee Speice
Cameron Taggart
Camille TJHOA
Chinedu Francis Nwafili
Chris Goller
Chris Kolodin
Christian Bourjau
Christopher Lane Hinson
Cldfire
Corbin Uselton
Corey Farwell
Craig Disselkoen
Dan Fockler
Dan Reeves
Daniel Gollahon
Daniele Esposti
Danielle Pham
Darren Tsung
David Flemström
David McNeil
David O’Connor
DebugSteven
Dimitrii Nemkov
Dmitry Kashitsyn
Eduard Kyvenko
Erick Tryzelaar
Erika Kloss
Evan Shaw
Felix Schütt
Florian Gilcher
Frank Hassanabad
Frazer McLean
Gergely Nagy
Guy Waldman
Hendrik Sollich
Henrik Sjööh
Herman J. Radtke III
Hidehito Yabuuchi
Ian Duke
Ian McIntyre
Ingvar Stepanyan
Ioannis Valasakis
Ivan Enderlin
J. Ryan Stinnett
Jamen Marz
Jamie Kyle
Jan Willem Henckel
Jan-Erik Rediger
Jannik Keye
Jason Davies
Jason Wohlgemuth
Jesper Håkansson
Jim Blandy
Joel Gallant
Johann Hofmann
Johannes Henninger
John Lewis
Jonas Trollvik
Jonathan Kingston
Jonathan Sundqvist
Josh Triplett
Joshua Liebow-Feeser
Joshua Sheard
Josmar Dias
João Lucas Lucchetta
Julius Rakow
Junjie Huang
Katharina Fey
Kevin Hoffman
Kirill Bulatov
Kyle Lin
Lachezar Lechev
Laurentiu Nicola
Liigo Zhuang
LongYinan
Luke Wagner
Mackenzie Clark
Mackiovello
Manas Karekar
Marcin Baraniecki
Mario Reder
Mark Andrus Roberts
Mark Hintz
Markus Stange
Mason Stallmo
Matias Insaurralde
Matt Harrison
Matt Howell
Matt Kraai
Matt Long
MaxD / vj userZero
MaxXor
Michael Gattozzi
Michael Gerhaeuser
Michael Hoffmann
Mirclus
Nathan Froyd
Nick Fitzgerald
Nik Graf
Nikolay Volf
Noah Lemen
Noumir Poutipou
OJ Kwon
Pascal Brandt
Pascal Hertleif
Pat Hickey
Peter Trotman
R. Andrew Ohana
Rahul Sharma
Ralph Giles
Renée Kooi
Ricardo Ambrogi
Richard Dodd (dodj)
Robert Masen
Roberto Huertas
Rongjian Zhang
Ruben Schmidmeister
Ryan Levick
Sallar Kaboli
Santiago Pastorino
Satoshi Amemiya
Scott Johnson
Sebastian Köln
Sendil Kumar N
Sergey Pepyakin
Sharad Chand
Sonny Scroggin
Sophie Alpert
Spencer Wilson
Stefan Novak
Stefan Zimmermann
Stephan Renatus
Stephan Wolski
Steve Klabnik
Sven Sauleau
T. Nagasawa
Tao He
Ted Mielczarek
Theemathas Chirananthavat
Thiago Pontes
Thomas Eizinger
Tim Ryan
Tobias Bieniek
Tomohide Takao
Tomáš Hübelbauer
Tyler Laing
Tyler Wilcock
William Lundstedt
YUyz
Yoshua Wuyts
Yury Delendik
Yuval Kohavi
Zachary Pierce
Zack Pierce
afdw
alkahest
andy-bell
arjunyel
ashley williams
belfz
bokuweb
bspeice
csmoe
data-pup
dependabot[bot]
frankhassanbad
gaurikholkar
gnzlbg
huangjj27
janczer
johnthagen
kohensu
konstin
kryptan
kzvi
limira
na-g
pup
robert masen
robertdurst
sarahmeyer
sepiropht
sigmaSd
soryrawyer
teovoinea
toversus
twilco
xeqlol

This Week in Rust and WebAssembly 009

2018-11-28T00:00:00+00:00

Hello and welcome to another issue of This Week in Rust and WebAssembly!

Rust is a systems language pursuing the trifecta: safety, concurrency, and speed.

WebAssembly is a stack-based virtual machine and instruction set. It is fast, safe, portable, and part of the open Web platform. By compiling to WebAssembly, we can run Rust code on the Web!

This is a weekly summary of Rust and WebAssembly’s progress and community.

Did we miss something? Tweet to us at @rustwasm or send us a pull request.

Want to get involved in Rust and WebAssembly? Join the Rust and WebAssembly working group!

News and Blog Posts

Want to make sure something ends up in this list on the next This Week in Rust and WebAssembly? Leave a comment on this issue.

Multithreading Rust and WebAssembly
Introducing the Ruukh Framework. An experimental next-gen frontend framework for the Web in Rust. GitHub repository.
The new website for the pest PEG parser generator has a nice wasm-based try-it-live demo at the bottom: https://pest.rs/
WebAssembly and Dynamic Memory. A comparison of portability of allocators for wasm, featuring wee_alloc.
Simi is a new, simple framework for building wasm-front-end Web application in Rust.
Encrusted is an interpreter for Infocom-era interactive fiction games like Zork that runs in your browser and is built with Rust and WebAssembly.
Using WebAssembly with Rust is a new, free Video Course on Egghead.
Pauan/SaltyBetBot is a SaltyBet Bot written entirely in Rust and stdweb and compiled to Wasm.
Serverless Rust with AWS Lambda and WebAssembly
Serverless Rust with Cloudflare Workers and WebAssembly
php-ext-wasm is a PHP extension written in C, calling a Rust lib through FFI, using wasmi behind the scene.
HOWTO: Setting up WebAssembly on stable Rust without rustup. Instructions on using raw Rust and Wasm if you happen not to have rustup available.
Wasmer is a WebAssembly runtime built on top of Cranelift.
Terrarium is a fork of WebAssembly Studio, except rather than run WebAssembly in your browser, it is deployed to a fastly server.
runwasm is an Emscripten emulation layer built with wasmi.
Bringing Elm’s architecture to Rust and Webassembly
Stanford’s CS 242 Programming Languages Class will feature Rust and WebAssembly.
The “Programming WebAssembly with Rust” book by Kevin Hoffman and published by Pragmatic Programmers is in beta and available for pre-order.
yiransheng/rust-snake-wasm is a snake game in Rust and WebAssembly.
console-web is a crate for writing to the console in wasm using wasm-bindgen.

Updates from `rustwasm/*`

wasm-bindgen 0.2.28 released! 🎉
wasm-pack 0.5.1 released! 🎉
Twiggy 0.3.0 released! 🎉
There are two new reference sections in the Rust and Wasm book:
1. Which Crates Will Work with Rust and WebAssembly?
2. How to Add WebAssembly Support to a General-Purpose Crate

Requests for Contribution

Join the Rust and WebAssembly Working Group!
- All issues labeled “good first issue” in the rustwasm/* repositories
- All issues labeled “help wanted” in the rustwasm/* repositories

Jobs

Fastly is hiring for work on their native WebAssembly compiler, which is written in Rust, based on Cranelift

Rust and WebAssembly

This Week in Rust and WebAssembly 15

News and Blog Posts from Around the Web

Updates from rustwasm/*

RFCs

New RFCs

Final Comment Period RFCs

Merged RFCs

Working Group Meetings

Gloo

wasm-bindgen

wasm-pack

Requests for Contribution

New Good First Issues

New “Help Wanted” Issues

Gloo Update: Onion Layers, Timers, and Events

Onion-Layered APIs

The Core: wasm-bindgen, js-sys, and web-sys

The callbacks Layer

Layering on Futures and Streams

More Layers?

Events

Get Involved!

This Week in Rust and WebAssembly 14

News and Blog Posts from Around the Web

Updates from rustwasm/*

RFCs

New RFCs

Final Comment Period RFCs

Merged RFCs

Working Group Meetings

Gloo

rustwasm.github.io

rust-webpack-template

Twiggy

wasm-bindgen

wasm-pack

wasm-pack-template

Requests for Contribution

New Good First Issues

Let’s Build Gloo Together

The Utility High-Level Libraries and Frameworks Provide

How Gloo Fits In

Where We’re Starting

This Week in Rust and WebAssembly 13

News and Blog Posts from Around the Web

Updates from rustwasm/*

RFCs

New RFCs

Final Comment Period RFCs

Merged RFCs

Working Group Meetings

rustwasm.github.io

twiggy

walrus

wasm-bindgen

wasm-pack

Requests for Contribution

This Week in Rust and WebAssembly 12

News and Blog Posts from Around the Web

Updates from rustwasm/*

RFCs

New RFCs

Final Comment Period RFCs

Merged RFCs

Working Group Meetings

rustwasm/rust-parcel-template

rustwasm/twiggy

rustwasm/wasm-bindgen

rustwasm/wasm-pack

Requests for Contribution

New Good First Issues

This Week in Rust and WebAssembly 11

News and Blog Posts from Around the Web

Updates from rustwasm/*

RFCs

New RFCs

Merged RFCs

console_error_panic_hook

js-sys

Updates from `rustwasm/*`

`wasm-bindgen`

`wasm-pack`

The Core: `wasm-bindgen`, `js-sys`, and `web-sys`

The `callbacks` Layer

Updates from `rustwasm/*`

`rustwasm.github.io`

`rust-webpack-template`

`wasm-bindgen`

`wasm-pack`

`wasm-pack-template`

Updates from `rustwasm/*`

`rustwasm.github.io`

`twiggy`

`walrus`

`wasm-bindgen`

`wasm-pack`

Updates from `rustwasm/*`

`rustwasm/rust-parcel-template`

`rustwasm/twiggy`

`rustwasm/wasm-bindgen`

`rustwasm/wasm-pack`

Updates from `rustwasm/*`

`console_error_panic_hook`

`js-sys`

`walrus`

`wasm-bindgen`

`wasm-snip`

`web-sys`

`wee_alloc`

`#RustWasm2019` Posts

Updates from `rustwasm/*`

`walrus`

`wasm-bindgen`

`wasm-pack`

Updates from `rustwasm/*`