Piotr Sarnacki (Nov 10 2024 at 21:29): Piotr Sarnacki (Nov 10 2024 at 21:29):When I was naming the project I knew about JAWS the screen reader, but I didn't think it would lead to any confusion as when you google for JAWS you get mostly pages about Jaws, the movie. A screen reader user mentioned that it's already sometimes hard to find information about JAWS in context of the browser (like javascript developer tools). @benmccann from SvelteKit suggested the name could be Jawsm (pronounced like awesome) and I like that, so I changed the name to avoid any confusion.
Christof Petig (Nov 11 2024 at 04:02):Given the maturity of the current WASI 0.3 prototype by Joel I feel you could take a look at it for any newly starting projects, as async becomes so much easier with 0.3. Feel free to ask questions here, I adapted the code for native compilation and found it easy to understand, given Luke's excellent presentation in Barcelona.
Christof Petig (Nov 11 2024 at 04:03):Also Joel will likely present more about it tomorrow at WasmCon.
Piotr Sarnacki (Nov 11 2024 at 13:57):Thanks for the info @Christof Petig, that's exciting! For now I'm using few functions from WASIp2, mostly subscribe-duration and maybe I'll add outgoing HTTP requests at some point to test things, but a broader WASI integration will come when I get to more builtin types and especially Node.js APIs. Which makes it even better, cause by the time I'm there, I'm guessing WASI 0.3 will be used more widely.
The only potential issue I can see is runtimes support. The code I'm generating is already hard to run almost anywhere without host extensions. For now I added a few simple pollyfill functions to mimic WASIp2 in Node.js/Chromium, but my aim is to be able to run on top of a bare runtime without any custom code. If Wasmtime gets WASI 0.3 support anytime soon, I will definitely give it a shot.
At the moment another blocker for using Wasmtime is the exception handling support, but when I finish await/generators I might just have the tools to rewrite try...catch into WASM code that doesn't need the feature.
Piotr Sarnacki (Jan 08 2025 at 19:29):I have a small, but I think exciting update: I have a first working PoC of async/await handling in JAWSM. I think there are some edge cases that it doesn't handle yet, but it handles await statements in conditionals and loops, so the rest is definitely doable. When I wrote the first post in this thread, on 9th of November, I said I'm working on async/await, but I dropped the work afterwards. The project was just not ready for that in terms of stuff supported then, and most importantly because of very limited tooling. Now that I generate most of the WASM code from Rust, adding new features got easier. On top of that, I also worked on a tool to traverse and modify WASM code, which made it much easier to implement.
I'm very happy with it, because this is one of the last two things that I still didn't confirm are doable (the other thing is generators support).
For those curious on the details, I use a WASM code transformer that splits WASM code at the await point, saves the state and the stack and restores the state. The effect is kind of similar to asyncify, but a bit more integrated into how I translate JS code. And also rather than unwind the entire stack I do more of a CSP style transforms, ie. a function using one await statement will become two functions - first function will keep everything before the await keyword and the second function will be called once awaited promise is resolved.
Last updated: Jan 24 2025 at 00:11 UTC