Comment by mrdoops | Hacker News Reader

Comment by mrdoops | Hacker News Reader

My favorite part about the presentation was the correlations between the DOM tree and a supervision tree. If you've looked into the Scenic project (https://github.com/boydm/scenic) you know how this Process & Supervision model shows real promise for client-side UI concurrency. As your states are changing you don't want one bad state to crash and cascade elsewhere - supervision trees lets you contain and recover from failures gracefully.

I'll be honest I didn't think it would be possible to implement something like the BEAM's preemptive scheduler in WebAssembly until I saw the presentation. Turns out it's very doable with continuations. The timing should be right in the next couple years as both Lumen and some of the bigger components of WebAssembly maturity kick into gear. Similar high level language/runtime -> WebAssembly projects like Blazor(C#) are also pending features like more native control over the DOM without going through JS interfaces (see here: https://github.com/WebAssembly/interface-types/blob/master/p... for more technical details).

Even if client-side UI frameworks don't pan out for Lumen, I can see Lumen being valuable for edge-computation especially where concurrency and fault-tolerance are important.

Thanks, we are not entirely convinced if a 1:1 relationship of process to DOM element is going to be where we land ultimately but it most definitely is a fun and interesting experiment. And it does align well with many of the OTP concepts. It really comes down to performance numbers and further research to know what the best direction a rendering engine should take. Personally, unless a rendering engine in Lumen is doing something OTPish (i.e. supervisor trees) I don't see the reason why people would choose a Lumen solution over existing works. I think I mentioned it in the keynote but the performance is secondary to the architectural perspective that Lumen can bring to client side development.

As Lumen continues to develop we'll continue to experiment with ideas and see what works best. I actually have a dbmon demo built but Hans and Luke were hand compiling the source and the DOM ast was just too much which is why the presentation had a very simple div/p tag. Once the compiler is ready for use I hope to write more about the dbmon demo and show of some crashing table rows. Should be cool!

How many bytes each process consumes when mapped to a single DOM element ?

We've done some benchmarking to help understand the differences: https://github.com/lumen/threading-benchmarks

The tldr is that with Web Workers as the threading model that browsers are forcing WASM to use the memory footprint for BEAM processes is going to be larger. This is of course a concern for us. We've been talking about distributing a many processes across a few WWs but ultimately we'd like to see the vendors give up on WWs are being the implementation of the WASM spec.

Yeah, at the very least I expect to see Processes used like Liveview when you need containers/reactors to state and/or run-time control for messages between components. I wonder if an approach like Svelte (https://github.com/sveltejs/svelte) where it compiles into DOM updating code can be enhanced with the concurrency the BEAM provides.

It's amazing so much has been done already considering the team only started last February. Writing all those BIFs can't be easy! Lumen is definitely a compelling challenge.

Reply on news.ycombinator.com