The threads seem really lightweight, but how would some typical frontend benefit from this?
The threads seem really lightweight, but how would some typical frontend benefit from this?
At ElixirConf I built a simple supervisor DOM tree model. When we are ready to implement it for real we're going to experiment with mapping the DOM to a supervisor. Each node being an element. This way events and rendering take place in each node in the supervisor tree. Rendering would be diff based and merged its way back up. Events would be captured as messages in the idiomatic Erlang/Elixir way.
This is all guess work right now and we don't yet know what will be practical vs what sounds good in theory.
However, we are dedicated to the idea that the programming model of the BEAM is one that complex client-side applications will benefit from over what JavaScript current offers.
There is a db_mon-esque implementation within the source and ultimately this is where the demo will live but for now (and the purposes of that demo at ElixirConf) I went in a different direction
Scenic has some interesting properties in that if a specific component has a code problem and fails/crashes, the supervision tree will bring it back to life. I'm curious to see what similar things one could do with Lumen for the web.
Components are already a very popular level of abstraction with Vue and React, probably others. So maybe there are useful things to bring from Scenic.
In Elixir, I can reason about the code being run in one process as though it were synchronous, because it kind of is. But I can do that without blocking anything else, which is also pretty important.
Asynchronous and event-driven code is already a fact in the browser so working with an ecosystem that is designed for that may prove a better experience.
I'm hopeful. Also, concurrency, staying of the render thread if possible. There's lots of fun to be had there.
Lumen seems to implement OTP patterns so that's why those things work on it.