I started working on porting an internal viz tool in the company I work at from JS to Rust/wasm 2 weeks ago. Thanks for writing this post mortem up, has made me think twice whether its worth the work.
I looked at the possibilities of porting parts of my 2D canvas library's code base over to Wasm (using either AssemblyScript or Rust) last winter. My thinking was that maybe some of the more intense calculation stuff - animating text along a path, particle calculations, complex filters, etc - could be delivered faster if they happened in Wasm.
I didn't take the idea forward because it would've been a heck of a lot of (unpaid) work requiring some fundamental rethinking of the library's architecture, together with learning Rust/AssemblyScript alongside Wasm best practices, etc.
But the main thing that held me back were the bad memories I had of all the work I did when I learned about web workers and attempted something similar a few years ago. That work added a lot of complexity to maintaining/using the library, but in the end failed to deliver the speed increases I was hoping for. The best work I did in 2020 was removing the web workers and their associated complexity from the code base and instead concentrating my efforts on finding speed gains in Javascript.
I love the idea of Wasm, and have had some success in getting code that exports to Wasm - for instance, MediaPipe's Selfie Segmentation ML model - to play nicely with the library[1]. But if I ever want a really fast, Wasm-enabled 2D canvas library I think the best approach would be to build the entire thing in Rust and just have a lightweight JS API to handle the DOM and user interactions.
rikroots|3 years ago
I didn't take the idea forward because it would've been a heck of a lot of (unpaid) work requiring some fundamental rethinking of the library's architecture, together with learning Rust/AssemblyScript alongside Wasm best practices, etc.
But the main thing that held me back were the bad memories I had of all the work I did when I learned about web workers and attempted something similar a few years ago. That work added a lot of complexity to maintaining/using the library, but in the end failed to deliver the speed increases I was hoping for. The best work I did in 2020 was removing the web workers and their associated complexity from the code base and instead concentrating my efforts on finding speed gains in Javascript.
I love the idea of Wasm, and have had some success in getting code that exports to Wasm - for instance, MediaPipe's Selfie Segmentation ML model - to play nicely with the library[1]. But if I ever want a really fast, Wasm-enabled 2D canvas library I think the best approach would be to build the entire thing in Rust and just have a lightweight JS API to handle the DOM and user interactions.
[1] https://codepen.io/kaliedarik/pen/PopBxBM (warning: the CodePen page will ask for permission to use your device's camera)