Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Point to component model instead of host bindings (fixes #3143) #3746

Merged
merged 2 commits into from
Dec 17, 2023
Merged

Point to component model instead of host bindings (fixes #3143) #3746

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
71ea295
Point to component model instead of host bindings (fixes #3143)
ydirson Dec 16, 2023
04d7815
Revert changes in code
daxpedda Dec 17, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
8 changes: 4 additions & 4 deletions guide/src/contributing/design/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ desired interface expressed in JS (classes, types, strings, etc) and the
`foo_bg.wasm` module is simply used as an implementation detail (it was
lightly modified from the original `foo.wasm` file).

As more features are stabilized in WebAssembly over time (like host bindings)
As more features are stabilized in WebAssembly over time (like component model)
the JS file is expected to get smaller and smaller. It's unlikely to ever
disappear, but `wasm-bindgen` is designed to follow the WebAssembly spec and
proposals closely to optimize JS/Rust as much as possible.
Expand Down Expand Up @@ -59,9 +59,9 @@ pub fn greet(name: &str) -> String {
```

Additionally the design here with minimal intervention in Rust should allow us
to easily take advantage of the upcoming [host bindings][host] proposal. Ideally
to easily take advantage of the upcoming [component model][component-model] proposal. Ideally
you'd simply upgrade `wasm-bindgen`-the-crate as well as your toolchain and
you're immediately getting raw access to host bindings! (this is still a bit of
you're immediately getting raw access to component model! (this is still a bit of
a ways off though...)

[host]: https://github.com/WebAssembly/host-bindings
[component-model]: https://github.com/WebAssembly/component-model
6 changes: 3 additions & 3 deletions guide/src/introduction.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,8 +7,8 @@ ecosystem][rustwasm]. If you're not familiar already with `wasm-bindgen` it's
recommended to start by reading the [Game of Life tutorial][gol]. If you're
curious about `wasm-pack`, you can find that [documentation here][wasm-pack].

The `wasm-bindgen` tool is sort of half polyfill for features like the [host
bindings proposal][host] and half features for empowering high-level
The `wasm-bindgen` tool is sort of half polyfill for features like the
[component model proposal][component-model] and half features for empowering high-level
interactions between JS and wasm-compiled code (currently mostly from Rust).
More specifically this project allows JS/wasm to communicate with strings, JS
objects, classes, etc, as opposed to purely integers and floats. Using
Expand All @@ -33,7 +33,7 @@ With the addition of [`wasm-pack`][wasm-pack] you can run the gamut from running
the web locally, publishing it as part of a larger application, or even
publishing Rust-compiled-to-WebAssembly on NPM!

[host]: https://github.com/WebAssembly/host-bindings
[component-model]: https://github.com/WebAssembly/component-model
[dom-ex]: https://github.com/rustwasm/wasm-bindgen/tree/master/examples/dom
[console-log]: https://github.com/rustwasm/wasm-bindgen/tree/master/examples/console_log
[perf-ex]: https://github.com/rustwasm/wasm-bindgen/tree/master/examples/performance
Expand Down
24 changes: 12 additions & 12 deletions guide/src/reference/attributes/on-js-imports/final.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,15 +9,15 @@ prototype chain of an object. Note that `final` is not suitable for accessing
data descriptor properties of JS objects; to accomplish this, use the `structural`
attribute.

[host-bindings]: https://github.com/WebAssembly/host-bindings
[component-model]: https://github.com/WebAssembly/component-model
[reference-types]: https://github.com/WebAssembly/reference-types

The `final` attribute is intended to be purely related to performance. It
ideally has no user-visible effect, and `structural` imports (the default)
should be able to transparently switch to `final` eventually.

The eventual performance aspect is that with the [host bindings
proposal][host-bindings] then `wasm-bindgen` will need to generate far fewer JS
The eventual performance aspect is that with the [component model
proposal][component-model] then `wasm-bindgen` will need to generate far fewer JS
function shims to import than it does today. For example, consider this import
today:

Expand Down Expand Up @@ -74,8 +74,8 @@ function with `getObject(arg0)` as the receiver.

But wait, there's still a JS function shim here even with `final`! That's true,
and this is simply a fact of future WebAssembly proposals not being implemented
yet. The semantics, though, match the future [host bindings
proposal][host-bindings] because the method being called is determined exactly
yet. The semantics, though, match the future [component model
proposal][component-model] because the method being called is determined exactly
once, and it's located on the prototype chain rather than being resolved at
runtime when the function is called.

Expand Down Expand Up @@ -106,14 +106,14 @@ export function __wbg_bar_a81456386e6b526f(arg0, arg1, arg2) {
}
```

Getting better! Next up we need the host bindings proposal. Note that the
Getting better! Next up we need the component model proposal. Note that the
proposal is undergoing some changes right now so it's tough to link to reference
documentation, but it suffices to say that it'll empower us with at least two
different features.

First, host bindings promises to provide the concept of "argument conversions".
First, component model promises to provide the concept of "argument conversions".
The `arg1` and `arg2` values here are actually a pointer and a length to a utf-8
encoded string, and with host bindings we'll be able to annotate that this
encoded string, and with component model we'll be able to annotate that this
import should take those two arguments and convert them to a JS string (that is,
the *host* should do this, the WebAssembly engine). Using that feature we can
further trim this down to:
Expand All @@ -126,10 +126,10 @@ export function __wbg_bar_a81456386e6b526f(arg0, varg1) {
}
```

And finally, the second promise of the host bindings proposal is that we can
And finally, the second promise of the component model proposal is that we can
flag a function call to indicate the first argument is the `this` binding of the
function call. Today the `this` value of all called imported functions is
`undefined`, and this flag (configured with host bindings) will indicate the
`undefined`, and this flag (configured with component model) will indicate the
first argument here is actually the `this`.

With that in mind we can further transform this to:
Expand All @@ -138,8 +138,8 @@ With that in mind we can further transform this to:
export const __wbg_bar_a81456386e6b526f = Foo.prototype.bar;
```

and voila! We, with [reference types][reference-types] and [host
bindings][host-bindings], now have no JS function shim at all necessary to call
and voila! We, with [reference types][reference-types] and [component
model][component-model], now have no JS function shim at all necessary to call
the imported function. Additionally future wasm proposals to the ES module
system may also mean that don't even need the `export const ...` here too.

Expand Down