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?
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?
Is handwritten javascript even a maintenence headache for the core team? Are there bugs that arise from the lack of compiler checks in the codebase? Would switching to wasm ease these pains? Would it add a significant amount of extra complexity to maintaining LV?
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.
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!
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.
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?
