fluencelabs/wasm-bindgen
1
0
Fork 0
mirror of https://github.com/fluencelabs/wasm-bindgen synced 2025-03-15 17:50:51 +00:00
Code Issues Projects Releases Wiki Activity
wasm-bindgen/README.md

80 lines
2.4 KiB
Markdown
Raw Normal View History

Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
<meta charset="utf-8"/>
Add CI and a small README
2017-12-18 14:49:04 -08:00
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
# `wasm-bindgen`
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
**Facilitating high-level interactions between wasm modules and JavaScript.**
[Introduction blog post: "JavaScript to Rust and Back Again: A `wasm-bindgen` Tale"][post]
Add a link to blog post in README
2018-04-20 11:34:34 -07:00
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
[host]: https://github.com/WebAssembly/host-bindings
Add a link to blog post in README
2018-04-20 11:34:34 -07:00
[post]: https://hacks.mozilla.org/2018/04/javascript-to-rust-and-back-again-a-wasm-bindgen-tale/
Add CI and a small README
2017-12-18 14:49:04 -08:00
Update readme links for the moved repository
2018-04-09 21:26:15 +02:00
[![Build Status](https://travis-ci.org/rustwasm/wasm-bindgen.svg?branch=master)](https://travis-ci.org/rustwasm/wasm-bindgen)
Fixup AppVeyor badge
2018-04-09 12:49:08 -07:00
[![Build status](https://ci.appveyor.com/api/projects/status/559c0lj5oh271u4c?svg=true)](https://ci.appveyor.com/project/alexcrichton/wasm-bindgen)
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
[![](http://meritbadge.herokuapp.com/wasm-bindgen)](https://crates.io/crates/wasm-bindgen)
[![](https://img.shields.io/crates/d/wasm-bindgen.svg)](https://crates.io/crates/wasm-bindgen)
[![API Documentation on docs.rs](https://docs.rs/wasm-bindgen/badge.svg)](https://docs.rs/wasm-bindgen)
Add CI and a small README
2017-12-18 14:49:04 -08:00
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
Import JavaScript things into Rust and export Rust things to JavaScript.
Add a basic README which at least attempts
2017-12-18 16:35:36 -08:00
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
`src/lib.rs`:
Add a basic README which at least attempts
2017-12-18 16:35:36 -08:00
```rust
Leverage new rustc wasm features This commit leverages two new attributes in the Rust compiler, `#[wasm_custom_section]` and `#[wasm_import_module]`. These two attributes allow removing a lot of hacks found in wasm-bindgen and also allows removing the requirement of `wasm-opt` to remove the unused data sections. This does require two new nightly features but we already required the `proc_macro` nightly feature and these will hopefully be stabilized before that feature!
2018-03-14 14:33:53 -07:00
#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
Add a basic README which at least attempts
2017-12-18 16:35:36 -08:00
extern crate wasm_bindgen;
use wasm_bindgen::prelude::*;
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
// Import the `window.alert` function from the Web.
Migrate from a macro to an attribute This commit migrates from `wasm_bindgen!`-the-macro to `#[wasm_bindgen]`-the-attribute. The actual mechanics of the macro are relatively simple in just generating some shims here and there, but wrapping everything in one huge macro invocation can often seem intimidating as it gives off this feeling of "oh dear anything can happen here!" Using an attribute should curb expectations much more greatly of "oh there's just some extra stuff happening behind the scenes". The usage is otherwise relatively straightforward and close to what it was before, but check out the DESIGN.md/README.md changes for more info!
2018-02-07 16:41:33 -08:00
#[wasm_bindgen]
extern {
fn alert(s: &str);
}
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
// Export a `greet` function from Rust to JavaScript, that alerts a
// hello message.
Migrate from a macro to an attribute This commit migrates from `wasm_bindgen!`-the-macro to `#[wasm_bindgen]`-the-attribute. The actual mechanics of the macro are relatively simple in just generating some shims here and there, but wrapping everything in one huge macro invocation can often seem intimidating as it gives off this feeling of "oh dear anything can happen here!" Using an attribute should curb expectations much more greatly of "oh there's just some extra stuff happening behind the scenes". The usage is otherwise relatively straightforward and close to what it was before, but check out the DESIGN.md/README.md changes for more info!
2018-02-07 16:41:33 -08:00
#[wasm_bindgen]
fix: remove unwanted no_mangle and extern wherever applicable
2018-03-05 23:25:15 +01:00
pub fn greet(name: &str) {
Migrate from a macro to an attribute This commit migrates from `wasm_bindgen!`-the-macro to `#[wasm_bindgen]`-the-attribute. The actual mechanics of the macro are relatively simple in just generating some shims here and there, but wrapping everything in one huge macro invocation can often seem intimidating as it gives off this feeling of "oh dear anything can happen here!" Using an attribute should curb expectations much more greatly of "oh there's just some extra stuff happening behind the scenes". The usage is otherwise relatively straightforward and close to what it was before, but check out the DESIGN.md/README.md changes for more info!
2018-02-07 16:41:33 -08:00
alert(&format!("Hello, {}!", name));
Add a basic README which at least attempts
2017-12-18 16:35:36 -08:00
}
```
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
Use exported Rust things from JavaScript!
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
`index.js`:
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
```js
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
// Asynchronously load, compile, and import the Rust's WebAssembly
// and JavaScript interface.
import("./hello_world").then(module => {
// Alert "Hello, World!"
module.greet("World!");
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
});
Generate TypeScript by default instead of JS This is what's needed in the immediate future anyway, so let's do that!
2017-12-19 19:06:48 -08:00
```
Add a basic README which at least attempts
2017-12-18 16:35:36 -08:00
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
## Guide
Rewrite the README using Webpack 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.
2018-03-02 20:11:30 -08:00
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
[📚 Read the `wasm-bindgen` guide here! 📚](https://rustwasm.github.io/wasm-bindgen)
Add a smorgasboard example
2018-03-02 20:19:39 -08:00
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
## License
Add CI and a small README
2017-12-18 14:49:04 -08:00
This project is licensed under either of
* Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or
http://www.apache.org/licenses/LICENSE-2.0)
* MIT license ([LICENSE-MIT](LICENSE-MIT) or
http://opensource.org/licenses/MIT)
at your option.
Make the README a landing page All the details are moved into the guide, where they can be properly organized and have a table of contents.
2018-06-19 11:10:41 -07:00
## Contribution
Point to the guide's contributing section instead of CONTRIBUTING.md
2018-06-19 11:49:34 -07:00
**[See the "Contributing" section of the guide for information on
hacking on `wasm-bindgen`!][contributing]**
Add CI and a small README
2017-12-18 14:49:04 -08:00
Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in this project by you, as defined in the Apache-2.0 license,
shall be dual licensed as above, without any additional terms or conditions.
Add section on node dependency in README
2018-02-23 14:52:45 +01:00
Point to the guide's contributing section instead of CONTRIBUTING.md
2018-06-19 11:49:34 -07:00
[contributing]: https://rustwasm.github.io/wasm-bindgen/contributing.html
Reference in New Issue Copy Permalink