These are bindings to JavaScript's standard, built-in objects and their methods
and properties.
This does *not* include any Web, Node, or any other JS environment APIs. Only
the things that are guaranteed to exist in the global scope by the ECMAScript
standard.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects
* backend comments complete
* better matching
* gen comments
* Add example
* Move test bindings gen to own fn
* move build step into build fn
* add fn to read js, refactor gen_bindings/test to allow for this
* Add comments test
* Update readmes
* add comments to travis
* fix broken tests
* +x on build.sh
* fix wbg cmd in build.sh
* Address fitzgen's comments
This is still a work in progress. Parse WebIDL source text and convert it into
wasm-bindgen AST, so that we can automatically emit bindings for the types and
functions described in the WebIDL.
This commit adds an example of executing the `wasm2asm` tool to generate asm.js
output instead of WebAssembly. This is often useful when supporting older
browsers, such as IE 11, that doesn't have native support for WebAssembly.
These functions are activated with the `serde-serialization` feature of the
`wasm-bindgen` crate. When activated they will allow passing any arbitrary value
into JS that implements the `Serialize` trait and receiving any value from JS
using the `Deserialize` trait. The interchange between JS and Rust is JSON.
Closes#96
Using `proc-macro2`'s `nightly` feature is a good default for most use cases.
However, it causes a build error if used together with crates such as
`cssparser` that also use `proc-macro2` from a build script.
This change adds a default enabled feature `spans` that users can disable if
they need to work around this conflict.
Fixes#160.
This commit adds support for both `#![no_std]` in the wasm-bindgen runtime
support (disabled by default with an on-by-default `std` feature). This also
adds support to work and compile in the context of `#![no_std]` crates.
Closes#146
Nowadays the compile times are mitigated with incremental compilation and
otherwise it's much more ergonomic to run only one test if they're all in the
same suite.
Right now Webpack probably has the most mature support for loading wasm modules,
so let's show off how to do that! Additionally this commits hello world as an
example to the repository.
