4 ms·

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 an

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!

truth_seeker 7y ago
How many bytes each process consumes when mapped to a single DOM element ?
- bcardarella 7y ago
  We've done some benchmarking to help understand the differences: https://github.com/lumen/threading-benchmarks 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.
mrdoops 7y ago
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 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.

truth_seeker 7y ago

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

bcardarella 7y ago
We've done some benchmarking to help understand the differences: https://github.com/lumen/threading-benchmarks 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.

mrdoops 7y ago

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 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.