Feature Request: Complete WASM Bindings for Subxt Client

[SailorSnoW]

It would be valuable to have comprehensive WASM bindings for Subxt clients, covering transactions, queries, and all types used within the client for operations. The goal would be to generate complete JS/TS bindings via wasm_bindgen for the entire Subxt library, which would make Subxt extremely powerful by enabling direct use of the Subxt interface in JS/TS applications.

Background

This idea emerged from our current effort to centralize all chain-related codebase in Rust. We've been exploring solutions like wasm_bindgen for our existing code, allowing non-Rust web developers to use our Rust-maintained tools. Currently, this requires us to wrap all possible operations using Subxt clients in a context that is JS-compatible and interfaceable (via wasm_bindgen on wrapper types).

Question

Do you think this feature could be implemented in the future? I understand this would be a substantial undertaking, but it would significantly expand Subxt's accessibility to the JavaScript/TypeScript ecosystem, and highly reduce verbosity for future projects that would like to adopt this architecture for their SDK.

[jsdw]

Hello!

This is something I've pondered before, but as you say, it would be a substantial undertaking, in terms of both development and added maintenance costs over time. The Subxt+WASM client would also have some significant overhead in terms of eg bundle size over using a pure TypeScript library (such as PAPI).

Normally I'd recommend:

• If you're building a TypeScript App: Use PAPI, which is built from the ground up for this use case
• If you're building a UI app in Rust (bit of a niche use case): Use Subxt compiled to WASM as a part of this app. No bindings required.
• If you're building an app in some language that isn't Rust of TypeScript: Use Subxt and write a minimal set of C bindings to expose the functionality you need to that language.

We may at some point in the future decide that it's worth working out how to generate and maintain bindings in several key languages (eg Python, Go, Java) to better support those user bases, and if we decide to head down this road then I could see supporting TypeScript bindings as being possible (though the path is different; via WASM rather than C).

In any case, it would be a significant amount of work, so I'd have to say that it's very unlikely that we'll take this path, at least in the short to medium term!