[glennsl]

Building an agtech platform (with quite a few other people, including a designer and data scientist, but I'm currently the sole developer, and for the most part it was built by a single developer).

Backend: Rust, rocket, sqlx, postgres + a little bit of R. Ansible for deployment.

Frontend: Rescript + React. Also a significant portion of Rust/WASM, but that was a mistake I'm trying to undo.

In short, statically typed and functional(-ish).

[farmin]

Nice. Are you able to share what you are working on and why WASM was a mistake?

[glennsl]

It's not easy to separate WASM specifically from Rust, and also hard to separate Rust from seed-rs, the UI framework we're using. But as far as problems with all of them together, here's the major ones:

- Very slow compilation times. A medium-sized app can take 30s to build incrementally on a fast desktop computer. And that's just way too slow for front-end development where fast iteration is key. In comparison, Rescript takes maybe a few hundred milliseconds on an app that's about the same size.

- Poor abstraction mechanisms, for making reusable and configurable components with more than a few properties, some being required and some being optional. The common Rust solution for this is the "builder" pattern, which is very verbose to implement, and still quite awkward if you have more than a few required properties.

- Poor debugging ability. WASM is opaque and there's no debugger for it as far as I know. The stack traces you get from Rust is also very noisy and imprecise. You basically only get the function name, and have to search for it in a big noisy stack trace. And because of inlining the problem might not actually even be in that function. Also, when a panic happens the app just freezes. There's probably some way of intercepting and overriding this behaviour, but by default it's quite bad UX.

- The cognitive overhead of manual memory management. Fighting the borrow checker and having to always think about who owns what and what strategy to use to manage data ownership is just completely unnecessary for most front-end development. Most of the time the app is just waiting for an event to happen, and when something does happen the processing needed tends to be dwarfed by the time spent by the browser to update and render the DOM.

- Large bundle size. Because you tend to use native Rust libraries instead of binding to non-idiomatic and often poorly designed browser APIs.

- Somewhat poor browser support? We've had some issues with the app simply failing to load after a new version is deployed, and having to clear the browser cache in order to fix it. We've yet to reproduce this reliably and therefore still haven't been able to track down why it happens.

[davidatbu]

I'm literally about to do my weekend coding on a WASM UI using sycamore-rs (a rust library), so I would love to find out too lol

[glennsl]

See the reply to parent. For a hobby project I think it's an interesting experience to try. Especially if you also intend to write a back-end in Rust. But for production use, and productivity in general, I don't think it's close to ready.

I find Rescript to be much more enjoyable for both hobby and production use. If you're looking for a front-end language that is quite similar to Rust, just without the manual memory management :)

[davidatbu]

Thank you so very much for sharing your valuable experience!