It's refreshing to see those kind of projects coming back on HN. Pretty awesome to see your example (https://evmar.github.io/theseus/) fit in about 1MB when a lot of those wasm projects can be super heavy (like libreoffice which is 50MB after brotli compression)
Seeing minesweeper recompiled to run in the browser is awesome.
The pain points about threading in the browser and debugging wasm are the two problems I ran into on another project. I hope we can get some improvements in both areas because wasm would be a lot easier to work with if developers didn't have to fight both of those topics.
An interesting learning project, but not actually usable.
https://github.com/danoon2/Boxedwine looks interesting in this space, but unfortunately it can't really run anything remotely modern in practice (though if you're looking at 20th century Windows software it will likely be capable of running it).
Seems like Theseus is not using OffscreenCanvas yet. Should be a good fit for something that runs off the main thread. Graphics can be rendered from a background worker thread directly to the screen without the involvement of the browser main thread at all.
I am unfamiliar with this project and only skimmed this post but if this uses Rust for the main binary blob it should be possible to have the main thread blob shared with the other threads even with the blocking.
The blog post cites the concern that malloc could block, however when Rust's standard library is compiled with support for atomics enabled the Rust allocator's locking implementation busy loops instead of waiting on the main thread.
This means that if care is taken to avoid any other code that makes the main thread wait it should be possible to use a single shared binary instead of the more convoluted approach presented in the blog post.
It's just a matter of time before we'll have a universal executable/binary translator that can run any program from any OS. These are artificial constructs when you think about it.
If you haven’t seen it, @jart’s Actually Portable Executable does just this - it’s definitely got a long ways to go (iirc it only supports CLI apps), but it’s fascinating to see a method of building binaries that can execute across various architectures and operating systems.
It simulates x86 (win32 and win16) and implements Windows APIs in javascript and renders window frames with DOM and contents with canvas (e.g. GDI translates to browser canvas operations). A lot of programs run already but a lot of APIs are not yet implemented.
I successfullt spent a few days extending it to run a Click & Create based game from my childhood.
14 comments
[ 3.0 ms ] story [ 29.2 ms ] threadThe pain points about threading in the browser and debugging wasm are the two problems I ran into on another project. I hope we can get some improvements in both areas because wasm would be a lot easier to work with if developers didn't have to fight both of those topics.
https://github.com/danoon2/Boxedwine looks interesting in this space, but unfortunately it can't really run anything remotely modern in practice (though if you're looking at 20th century Windows software it will likely be capable of running it).
https://github.com/WebAssembly/component-model/blob/main/des...
Threading is actively being worked on right now (to be released in 0.3.x, soon), and some changes just made their way into LLVM as well:
https://github.com/llvm/llvm-project/pull/175800
These branded projects become difficult to remember when everything has a random non-mnemonic name.
It too uses WASM, but for running non-Rust programs in sandboxes. Everything else is Rust. Hmm.. Last updated in 2024 though.
0: https://github.com/theseus-os/Theseus
https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCa...
The blog post cites the concern that malloc could block, however when Rust's standard library is compiled with support for atomics enabled the Rust allocator's locking implementation busy loops instead of waiting on the main thread.
See the comment in the Rust source here: https://github.com/rust-lang/rust/blob/77a4fb62f70c6ea05e182...
This means that if care is taken to avoid any other code that makes the main thread wait it should be possible to use a single shared binary instead of the more convoluted approach presented in the blog post.
It's just a matter of time before we'll have a universal executable/binary translator that can run any program from any OS. These are artificial constructs when you think about it.
https://retrotick.com/
It simulates x86 (win32 and win16) and implements Windows APIs in javascript and renders window frames with DOM and contents with canvas (e.g. GDI translates to browser canvas operations). A lot of programs run already but a lot of APIs are not yet implemented.
I successfullt spent a few days extending it to run a Click & Create based game from my childhood.