I’ve been reading up on Firefly and it looks very impressive. Does this mean faster CPU bound Elixir? i.e. ballpark java speeds? Or at least tighter interop with Rust would be fantastic with what they mentioned in NIF section.
I also found Hologram which I think leverages Firefly to put Elixir client side and it made me drool a little.
Stuff like this makes me very excited about the beam garden.
Hey, the creator of Hologram here. Hologram is not using Firefly under the hood - it transpiles BEAM definitions directly to JavaScript, and it has a different scope than FireFly in general, think ElixirScript + LiveView + Surface. Btw expect playable version soon! 
I suppose none of the VM features are available, it is basically just limited elixir syntax?
You can say so, it won’t support the stuff related to processes, at least in the initial versions. However I plan to experiment with Web Workers API later to see what can be done in this regard.
Thanks for clarification. Really like the page localization layout. Also do you have plans to make this work with Firefly in future?
If it will have some dead-code elimination and code-splitting methods, then why not? I’d like to avoid having to ship a few MB runtime bundle to the browser on the initial page load. With the current architecture, Hologram is able to run a basic page with a few kB runtime bundle and a few kB page-related bundle.
Yeah, but don’t forget that you will have VM capabilities, like processes and fault-tolerance, witch IMO is worth even the full VM size (witch is currently about 30 MB), ofc this is not for all cases.
Yeah, I think it would be helpful, but for more complex cases than reactive UI. Maybe something like client-side file processing to relieve the server resources? In case processes are needed, the Hologram commands can be used that handle asynchronous server code (where you basically run on BEAM) and they have very low latency since they go through websockets similarly to LiveView events. Btw do you have ideas on how BEAM capabilities can be used on the client side, besides file processing that I mentioned?
I think the potential is unlimited, you basically have the full-blown elixir/erlang capabilities at your disposal. You can write the part that is responsible for interaction with dom (from what I remember webassembly standard doesn’t include this) and write entire frontend applications in elixir, not having to go back to JS ever again.
Liveview is great, the biggest selling point is that you don’t have to write JS, however it has limitations for more involved applications, and currently people end up using a frameworks like react to solve this limitation, which is not something I enjoy doing.
For more possible features, think of applications as the native ones we use, the only difference is that it lives in browser.
I completely agree about the benefits of using Elixir on the client. That’s precisely what Hologram aims to achieve, with state management on the client and full Elixir syntax coverage. My point is that I’m currently exploring use cases for Elixir’s concurrency in the context of UI on the client. Given that the DOM operates on a separate single thread and WebAssembly cannot directly access it, there may be limited advantages, aside from potentially enabling background file processing. However, I acknowledge that I could be mistaken in this regard, and I’m seeking other potential use cases and opinions.
Disregard. I got Lunatic ( https://lunatic.solutions/ ) confused with Lumen, which was rebranded as Firefly. Carry on.
Last I heard Firefly was on hold for the WASM spec to mature. I’m sure someone closer to the project can provide more detail, but it ain’t cheap to pay for the kind of expertise Firefly needs, and if the spec still needs to make progress the opportunity cost might not make sense at the moment.
© Copyright Elixir Forum | Terms | Privacy & Cookies
