I just wish I could determine what I want as a reference and what I want as a value in JavaScript. I hate not being able to determine it myself and be constrained by a spec while not having any other language to use (no I'm not gonna use webassembly for everything).

There is a strong case for all business logic eventually being in wasm. It'll still need the js bridge though, so we'll just have to keep dealing with a lot these painpoints until we get wasm to SomeOtherDOM (SODOM?)

@SortOfTested Why should wasm handle all business logic?

@theuser
Just to name a few reasons:

- Higher performance
- separate the processes working with data from the processes that show it (memory sandbox)
- leverage a more robust set of languages
- better memory usage
- real multi-threading
- higher security environment opens the door for most robust access to native apis

That's just the tip of the iceberg. There's still a place for js code, but client-side encapsulation of business logic in a secure sandbox that users can't modify means you can push more workloads downstream to hardware you don't have to pay for.

Obviously when I say "all" business logic it's in the context of this discussion (logic handled by JS), I'm referring to all business logic that would otherwise be in JavaScript. There will obviously still be business rules that are located inside of the server APIs.

@SortOfTested Well looks like the client side is doing more processing then, which some devs may not agree with. Client-side processing is free processing though.

@theuser
Well, if you're running js payloads on the server, those can be wasm as well, and benefit from the perf improvements. That said, if you're going to the trouble of writing the logic in rust or similar, you should probably just be using actix or rocket instead.

Even as aged JS dev, I'm very looking forward for everything->wasm, because then I can try any language for web frontend - all without losing power on JS endpoint monopoly and with performance gain. 👍