We are pleased to announce the first release of the web-sys crate! It provides raw bindings to all the Web’s APIs: everything from DOM manipulation to WebGL to Web Audio to timers to fetch and more!
Almost three months ago, we laid out our vision for wasm-bindgen:
We are building a shared foundation for an ecosystem of Rust crates that target JavaScript environments with
wasm-bindgen. Sharing a foundation means sharing rawexternimports. Every library that uses the Web’swindow.requestAnimationFramefunction or ECMAScript’sObject.freezefunction shouldn’t need to write theexternimports themselves.
We observed that the Web has a huge number of APIs and that adding support for all of them by hand would be a Sisyphean task. However, all these APIs are standardized with the same interface definition language, and we realized that we could leverage that to mechanically generate a crate containing every single Web API:
All of the Web’s API types, functions, and methods are specified with WebIDL, so we are working on a new WebIDL frontend to
wasm-bindgen. When the WebIDL frontend is ready, we plan on taking the interface definitions for all the Web APIs from all their standards and automatically generating a big-sysstyle crate from them.
wasm-bindgen’s new architecture with its WebIDL frontend.
This plan has finally been realized in the web-sys crate! We added a frontend to wasm-bindgen that slurps in WebIDL interface definitions and emits wasm-bindgen’s internal abstract syntax tree (AST). This frontend is the wasm-bindgen-webidl crate. Once we have the AST, emitting zero-overhead Rust and JavaScript glue code to do type conversion and shepherding of function parameters and return values is the same as normal #[wasm_bindgen] annotations.
Is using WebIDL to mechanically generate glue code a new idea? Nope! This is the same battle-tested strategy that every browser engine uses to generate JavaScript-to-C++ glue code (or in Servo’s case, JavaScript-to-Rust) for its implementation of these APIs. Furthermore, it is yet another way that wasm-bindgen is future-compatible with the host bindings proposal. The host bindings proposal will allow WebAssembly to directly call into native DOM methods without going through a JavaScript shim, promising to eventually unlock even-faster-than-JS DOM performance since calls from wasm can be statically validated to type check once at compilation time, rather than dynamically on every single call. The proposal suggests that the interface to the host’s bindings be generated mechanically from WebIDL, and we are doing exactly that.
js-sys crate is 100% feature complete!
A related bit of news is that the js-sys crate is now 100% feature complete! It contains raw bindings to every ECMAScript API (those APIs that are available both in Node.js and on the Web and any other JS environment).
Unlike the web-sys crate, these are written by hand because there is no WebIDL describing these APIs. That would have been great to have, both because it would have been easier to implement the js-sys crate, and because we would have avoided bugs along the way. We considered a TypeScript frontend, but did not prioritize it because TypeScript does not describe whether or not functions throw exceptions.
We have a growing list of examples of using web-sys, js-sys, and wasm-bindgen together! The following programs are a small selection of these.
Click and drag to draw!
More information and source code.
An FM Synthesizer with Web AudioThis example creates an FM synthesizer using the WebAudio API and web-sys.
More information and source code.
Friends 💖 Contributors toweb-sys and wasm-bindgen-webidl
Huge thanks to everyone who helped build the web-sys crate and the Web IDL frontend for wasm-bindgen that made the web-sys crate possible!
js-sys
A second round of applause for everyone who contributed to the js-sys crate!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4