Recently Chris McCord’s talk about Phoenix LiveView at ElixirConf EU 2019 just came up in my YouTube feed:
In his talk Chris initially explains how you can write interactive web apps without JS with a catch: that you don’t need to write JS for your app, but that it is used by LiveView anyway. From the user’s point of view this is fine, as it is not they who has to write and maintain that JS.
However with technologies such as wasm and the Rust backed for wasm slowly maturing, it seems to me that it is possible to rewrite the websocket client on LiveView in Rust + Wasm and eliminate all JS with the exception of glue code generated by the compiler.
Since I have never contributed to LV, and thus not aware of the nitty gritties of the websocket client’s implementation, the core team’s overall satisfaction with the client as well as with JS, and the time and effort required to maintain the client, I have a few questions:
Is writing the websocket client even possible with WASM? Is there some technicality which makes a fully functioning wasm client impossible?
Does the core team consider WASM and the Rust backend for WASM or even any other language that compiles to wasm mature enough for use in LV?
Would wasm lead to any performance gains at the client side? Will there be any performance improvements or decreased memory use by using wasm. Would switching to wasm improve LV’s performance in this scenario?
Apart from the marketing tagline of “No JS in the codebase at all”, is there any sense in using WASM?
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.
For this reason, currently people are finding most success with WebAssembly for algorithmic / compute-intensive tasks.
Wouldn’t switching to WebAssembly post v1.0 create friction in switching instead. I thought staying in v0.x gave the core team more flexibility to make drastic changes.
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.
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?