Benjamin-Philip
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?
-
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?
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #ai
- #phoenix_html
- #iex
- #elixirconf-us
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
derpycoder
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!
aschrijver
As somewhat related I’ll drop a link to this ElixirConf talk: https://www.youtube.com/watch?v=l0QS_iXlQto
Benjamin-Philip
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.
wanton7
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.
evadne
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?
derpycoder