(I asked): what's the reason for async requiring its data to be 'static? I want to say it's because of multithreading, that the async runtime is free to move everything between threads... but that doesn't apply with JS...
Pauan answered:
@dakom nothing to do with multithreading all heap allocated things must be 'static, because they outlive the stack references are always on the stack therefore they cannot outlive the stack so if you put something onto the heap... such as by using Box, or Rc... then the stuff contained inside the Box or Rc must be 'static in other words, it cannot contain references because those references would live in the heap but the heap outlives the stack therefore you would have a use-after-free obviously async code lives in the heap it must live in the heap because it outlives the stack
if async did not outlive the stack, then it would not be async because it would have to run synchronously within the current stack frame like a regular sync function but it doesn't do that, it runs asynchronously in the background therefore it must be in the heap therefore it cannot contain references so it doesn't matter whether it's multithreaded or not it has to do with stack vs heap same reason why if you do Box it requires Foo to be 'static the only way you can have references with async code is if you use block_on because block_on will block the current thread until the async code is finished which means that the async code runs synchronously within the current stack frame so block_on converts an async function into a sync function however block_on does not work with Wasm, because browsers do not allow you to block the current thread so in Wasm, all async code is asynchronous, and therefore lives in the heap the way to think of it is... "when this function call is finished, does it clean up all the data, or does the data outlive the function call?" if the data outlives the function call, it's heap allocated obviously when you call an async function, the Future outlives the function call
as for .future... unlike JS, Rust Futures are cancelable so for example, if you're loading some data from the server, you can cancel it halfway through (you can't do that with Promises, but you can with Rust Futures)
if you use spawn_local, the Future will never be cancelled it will always run to completion if you use .future, then when the Dom is removed it will automatically cancel the Future so let's say you display some Dom
then when it's half-way done you remove the Dom (like let's say the page changed or something) you want the data loading to be cancelled, since it's not needed anymore, since the Dom is gone that's what .future does, it cancels the Future when the Dom is removed