[ec109685]

What was the reason for web assembly versus just running rust directly on the target hardware? Is the idea that the constrained WASM environment requires less QA than if the hardware was targeted specifically by the rust compiler?

[aylmao]

It's an alternative that gives them the updatability of JS. When they describe their original (JS/C++) architecture they mention this as a motivating factor:

> This architecture split allows us to deliver new features and bug fixes without having to go through the very slow process of updating the C++ layer. The downloadable code is delivered through a fully automated continuous integration and delivery pipeline that can release updates as often as every few hours

They do support a lot of device types, which means a lot of compilation to produce many different binaries and probably more reliance on the app update systems of third parties.

[AmyNever]

>probably more reliance on the app update systems of third parties.

Exactly right. Big platforms with guaranteed support is one thing, but here's the situation for smart TVs right now:

It's 2022. You build an app for SuperScreen's latest range of smart TV. You update it every so often, and SuperScreen are happy to certify those updates and help you push them.

It's 2023. You port your app to SuperScreen's latest range of smart TVs. You keep updating your 2022 app, but SuperScreen are slightly less helpful now, as most of their attention is focused on the 2023 set (and upcoming 2024 range).

It's 2024. You port your app to SuperScreen's latest range of smart TVs. But when you want to update your 2022 app, SuperScreen say "hmm, we don't really have a lot of time now to certify apps for these older devices, please try to make as few updates as possible". It's a little tough but you have to do it, as the alternative is that 2022 TVs don't get any of your new features.

It's 2025. You port your app to SuperScreen's latest range of smart TVs. But now SuperScreen refuse to certify updates to your 2022 app saying "these are legacy devices and we can't justify the time or effort to certify apps on this platform any longer... unless you were to pay us a LOT of money".

You might get approval for one last update, paying SuperScreen the money, and then you effectively mothball your 2022 app. It becomes a "legacy" app for you as well, stuck in maintenance mode, not getting any updates or new features. And this is on a TV that is only four years old. So the best way forward is to make your native layer as small and light as possible, and shift all of the heavy lifting into the runtime client layer. If most of your client UI is a downloadable JS / WASM runtime, then you can keep supporting it even if the platform owners don't want to play ball any more.

[ec109685]

Is there enough security that would prevent downloading a binary / full and running that versus downloading JS / WASM?

[exdsq]

If you target a WASM VM you’re not tied into Rust itself which seems appealing from a risk standpoint

[root_axis]

How so? Your source code is still in Rust so seems like you'd still be tied to it.

[rafale]

The source code is in Rust. But the compilation target is WASM instruction set.

[root_axis]

Why does that matter with respect to being less tied to rust? Yes, it compiles to WASM but your engineers still have to write rust in order to make changes to the software. I mean I suppose they could edit the WASM directly since it's technically human readable, but if you're doing that why bother with rust at all?

[exdsq]

In terms of platform support - if you target a VM you don’t have to worry about moving from Rust because another language might not support that runtime. Now any language that can work on a WASM VM is okay. Also, if the app isn’t monolithic it means supporting services can be in other languages than Rust too.

[jedisct1]

ELF, COFF, Mach-O, etc. objects can already be linked together regardless of the compiler producing them.