In the talk on LiveView native, linked below, this point was raised towards the end.

A common core, written in rust perhaps, can be used to jump start anyone approaching LiveView implementation in any platform.

LiveView is not yet in version 1, so jumping straight to a static typed language without fleshing out the needs of users will just introduce unnecessary friction.

Also, WebAssembly has no direct DOM access, so despite its superior performance, you may find that it is slower than JavaScript for LiveView use case due to extra I/O overhead.

For this reason, currently people are finding most success with WebAssembly for algorithmic / compute-intensive tasks.

And for DOM stuff, LiveView will still need JavaScript, until Webassembly Interfaces becomes standardised!

Why would it matter to what language underlying tech is using if you don’t have to use it yourself? LiveView isn’t going to use WASM because why would it? There is not need to use some newer tech just because it’s there.

I think LiveView is more about allowing you run your UI code at server side for simplicity than removing JavaScript. One big thing about it is that you don’t have to write an API. Sometimes you still want to use JavaScript & JavaScript libraries in browser when you want something extra. If client would be using WASM it’s possible it could be harder for developers to use and client might be slower than now because my understanding is that communication between WASM and JavaScript isn’t that fast.

WASM isn’t currently in a place where it’s replacement for JavaScript. So you would still need some JavaScript even if you write some parts in WASM. JavaScript has been around for a long time, it’s mature, quite performant with new JavaScript engines and there are lot of libraries for it. For compiler checks (static typing) LiveView team could just switch to using TypeScript.

I don’t understand this JavaScript is bad and shouldn’t be used mentality. It has its quirks but it’s perfectly fine for lot of things especially for browser and if you use TypeScript to create type system top of it works quite well even for larger code bases.

Moving client logic from JS VM to WASM does not reduce the total amount of logic. However it would free up the main thread for interactions (an axiom known for 20+ years since 1st desktop was written). A relevant example would be like PDF.js splitting the rendition process into a separate worker (some commercial products use the same strategy).

The main cachet of LV is server-side computation of DOM diffs and client-side patching of DOM utilising a persistent two-way connection. Explicitly and implicitly therefore, LV is coupled with DOM (joined at the hip if you will). There may be merits if we were to move some shadow DOM operations off the main thread for optimisation reasons (speaking from a super high level), however I do not see this sort of complexity provide any tangible benefit for the median use case of LV. Those folks who need it, would probably fare much better using SproutCore, Ember, React or some other 10-year-old “desktop class web apps” framework (so they have matured enough and actually have basic things) and use Phoenix sockets for fast backend interop

Why exterminate JS when it has served us so well since 1995?