3 ms·

This is an interesting read both as a general startup post-mortem but particularly in relation to WASM and it’s use for “speeding up” apps. I think it’s becomi

This is an interesting read both as a general startup post-mortem but particularly in relation to WASM and it’s use for “speeding up” apps. I think it’s becoming clear that as a general replacement of JS WASM isn’t going to achieve what some people are suggesting it could. However it certainly has its place, I’m super excited about being able to use things such as SQLite in the browser and other “lower level” toolkits from reusing existing desktop library’s. That’s where I think it’s going to have enormous success.

jitl 5y ago
After the article I’m still left wondering “well, what if my WHOLE app WAS Rust???”. Probably it would be faster in that case! But also, we wouldn’t be able to hire or write code as fast, and new people would take longer to onboard. But we could use expressive APIs without slowing down our app. As with any FFI system, you pay substantial cost in complexity and to some degree serialization for every function call. But if your app itself - the code in the driver seat - is all inside WASM and you optimize for minimum calls to a framework to touch the DOM by rendering to WebGL, maybe it can be much faster.
- Jasper_ 5y ago
  The current state of WASM is not really at this level yet. You can't call directly into the browser APIs from WASM, you need a JS layer to do the API call, and that involves interpreting WASM linear memory. This is slow. Yes, interface-types is supposed to fix this, but it hasn't; it's caught up in a bunch of spec drama, just like the GC proposal. WebGL still requires a lot of API calls per frame; WebGL 2 is better because of UBOs and VAOs, but not substantially. The rust/wasm story is also really bad right now; the latest wasm-pack release has been broken for 6 months now (corrupt release tarball) with nobody interested in fixing it, and wasm-bindgen is practically on life support. Debugging is such a sad experience, too. I regret trying to use rust/wasm, personally.
  - jitl 5y ago
    Bummer! I hope interface types get well soon.

jitl 5y ago

After the article I’m still left wondering “well, what if my WHOLE app WAS Rust???”. Probably it would be faster in that case! But also, we wouldn’t be able to hire or write code as fast, and new people would take longer to onboard. But we could use expressive APIs without slowing down our app. As with any FFI system, you pay substantial cost in complexity and to some degree serialization for every function call. But if your app itself - the code in the driver seat - is all inside WASM and you optimize for minimum calls to a framework to touch the DOM by rendering to WebGL, maybe it can be much faster.

Jasper_ 5y ago
The current state of WASM is not really at this level yet. You can't call directly into the browser APIs from WASM, you need a JS layer to do the API call, and that involves interpreting WASM linear memory. This is slow. Yes, interface-types is supposed to fix this, but it hasn't; it's caught up in a bunch of spec drama, just like the GC proposal. WebGL still requires a lot of API calls per frame; WebGL 2 is better because of UBOs and VAOs, but not substantially. The rust/wasm story is also really bad right now; the latest wasm-pack release has been broken for 6 months now (corrupt release tarball) with nobody interested in fixing it, and wasm-bindgen is practically on life support. Debugging is such a sad experience, too. I regret trying to use rust/wasm, personally.
- jitl 5y ago
  Bummer! I hope interface types get well soon.