wasm-ucan

[expede]

This is less of a spec-level concern, and more of an ecosystem one. Happy to move the topic elsewhere if there's a better place.

Something that has come up a few times is using rs-ucan to target both native code and Wasm, and then writing bindings into various languages (e.g. ts-ucan would become a layer on top of a UCAN Wasm UCAN, rb-ucan would wrap a native binary, etc).

This would save maintainer overhead, but we haven't tried this strategy in production yet. Wasm-flavoured Rust is certainly more constrained than arbitrary Rust, will sharing a common core restrict the wrapper language's APIs, how much of the project can be Wasmified, etc.

Just to toss my own hat in the ring, I'm all for trying this approach, but would love to know what others think.

[cdata]

I have to examine this more thoroughly to be sure, but my working hypothesis on this topic is:

For apps that already use a lot of Rust-based WASM to do authz stuff, using rs-ucan in WASM will feel natural and good.

For apps that are primarily written in TS/JS and rely mostly on TS/JS tooling and distribution mechanisms, a "native" JS implementation will be most welcome. There is a fair chance that a JS implementation will be smaller over the wire. Also, the tools have a better chance of successfully applying bundle optimizations to a JS module graph than a WASM blob.

That said, there is relatable appeal to having a single implementation for both environments (and possibly for other languages as well).

[dOrgJelli]

I think a TS/JS native devexp can still be achieved, while having the majority of your business logic run as Wasm modules. Also if a standardized ABI exists that describes the functionality within your Wasm module, you can codegen the TS/JS SDK so you don't have to manually maintain it.

The Polywrap toolchain (while still early) supports this today, you would simply:

• Develop a wasm wrapper in Rust (examples here)
• Codegen a TypeScript SDK (demo app here)

Docs for Rust->Wasm wrapper dev & app codegen are still OTW, but it's functional and shipped :)

[cdata]

You're right, it's possible to distribute a package such that it might be easily integrated into some projects. However, it's important to separate what is possible from what is accessible. The future is already here, it's just not very evenly distributed (as they say).

If we are talking about JS toolchains on average, we should ask ourselves: can someone with a Webpack, Rollup or Parcel-based toolchain incorporate this package as a dependency without needing to consider that a WASM blob is in the mix?

If the answer is "no," then there has been some reduction in the quality of that person's DX (and possibly also the end-user's UX).

Speaking for myself, I'm writing a Rust app that gets deployed to the web, so I'm generally in favor of the direction suggested by @expede . I just want to extend some sympathy to the non-Rust-writing general population of web front-end folk out there who are fighting to keep their bundle sizes down with popular-but-aged toolchains.

[bgins]

We came across an article from earlier this year that may help to answer some of these questions: https://nickb.dev/blog/recommendations-when-publishing-a-wasm-library/. I'd add Vite to the list of bundlers to consider. It's commonly used in Vue and Svelte projects.

It might be worth experimenting with a simple proof-of-concept library loaded with a variety of bundlers. We have a webnative-bundler-test that could be a good starting point. It currently tests Webpack, Parcel, Vite, Snowpack, and Estrella.

[cdata]

On the topic of Rust language constraints on the web, the number one thing that has bothered me is: async fns in traits. More specifically: there is no language support for async fns in traits (support is coming). There is a popular macro that sort-of gets you async fns in traits: https://crates.io/crates/async-trait. However, if you are like me and you deploy to both web and not-web, you end up using it like this in order to skip the Send bound on web only:

#[cfg_attr(not(target_arch = "wasm32"), async_trait)]
#[cfg_attr(target_arch = "wasm32", async_trait(?Send))]
pub trait StorageProvider<S: Store> {
    async fn get_store(&self, name: &str) -> Result<S>;
}

This leads to a lot of macro / type noise for us that varies depending on the other bounds needed for the trait.

[cdata]

Note that the macro noise must be added at the trait definition and also per trait implementation (unless you know the implementation is only used on one target).