Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
This would enable Turtl web clients. Not that I personally approve of web clients, but who am I to judge?
The core is in Rust, and Rust uses LLVM, and LLVM has a WASM target, so a majority of the work is done. I think the real issue is picking apart every single little issue that each crate has with being compiled to WASM. Also not sure about threading support and all that. I think FS support works via IndexedDB, but we use synchronous FS access and IDB is async...so how the hell does that work? Lots of questions.
I'm moving this to roadmap. Not sure when it will get in, but I'm actually thinking this is more and more important. I'd like to launch a web version of Turtl at some point, and just be explicit about the dangers of it. Also, I know the Framanotes folks would like this as well.
I did some work on this this past week. I ran into some issues...mainly some of the libraries turtl-core depends on use the
I'm not exactly sure where to go from here. It seems rust itself compiles just fine to wasm, but when linking against C libs, it would need to make assumptions that would probably break things. There are two paths forward:
Note that there is an example of a conversion of compiling libsodium to wasm (https://github.com/alexcrichton/wasm-sodium) but it is old and full of horrible warnings. Plus that does still leave openssl (although this dependency will be dropped in wasm because it would primarily be used for the HTTP client, and wasm already has XHR). So, really, just libsodium...
…dium and its dependency on libc (detailed a bit in turtl/tracker#52). committing my changes for now.