Compile core to WASM

[orthecreedence]

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.

---

Some resources:

• https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm
• https://rustwasm.github.io/2018/09/26/announcing-web-sys.html
• https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.XmlHttpRequest.html (will have to replace reqwest)

[orthecreedence]

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.

[ldidry]

Also, I know the Framanotes folks would like this as well.

Awww… 🤗 ❤️

Thank you!

[orthecreedence]

Of course!

[orthecreedence]

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 libc rust crate which does not define a lot of values needed when compiling the wasm target. See:

• Does it make sense to support WASM? rust-lang/libc#858
• Web Assembly support sfackler/rust-openssl#1016

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:

1. Wait until rust/c play nicely together when targeting wasm. Obviously this is a waiting game.
2. Replace all non-rust dependencies with rust-specific libraries (basically get rid of all *-sys crates). SQLite seems to work fine, actually, but openssl/libsodium (our heroic crypto libs) are problems. I haven't seen any pure-rust libraries that provide all the needed alternatives. Also, I don't like this route as much, because at some point we're going to want to do things like OCR and that really does require C libraries. In other words, playing nicely with C is going to be needed eventually, like it or not.

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...

[orthecreedence]

Note: currently blocked by koute/stdweb#398.