Couldn't you leverage wasm and run the client-side actor locally and achieve something similar without having to compile to JavaScript which is brittle and not fun at all?
Wasmex is an interesting project, but there's an important distinction to clarify: Wasmex isn't actually a compiler that would transpile Elixir to WASM. Instead, it's a bridge that allows you to call existing WASM modules from Elixir code running on the server/BEAM VM.
Even if we had a hypothetical Elixir-to-WASM compiler, I believe transpiling to JavaScript offers several advantages for Hologram's use case:
- Bundle size: JavaScript bundles are much smaller since we only transpile the code that actually runs on the client, rather than shipping an entire runtime.
- DOM access: WASM doesn't have direct DOM access - it still needs to go through JavaScript APIs. This creates an additional communication layer and overhead for every DOM operation, which is frequent in UI frameworks.
- Communication overhead: The boundary between WASM and JavaScript has performance costs for frequent data exchange, which would impact things like event handling and state updates.
- Debugging experience: The transpiled JavaScript code remains readable and debuggable with familiar browser dev tools, making development much more pleasant.
- Selective transpilation: We can leverage high-level JavaScript functions and browser APIs directly instead of having to transpile every single operation from scratch.
- Performance: For Hologram's use case (UI logic, state management, event handling), the performance difference between JS and WASM is negligible. WASM really shines for CPU-intensive computations, which isn't our primary bottleneck.
The JavaScript approach gives us the right balance of performance, bundle size, and developer experience for a client-side UI framework.
Maybe using something like https://github.com/tessi/wasmex
Never tried it, so I don't know what the limitations would be, but it seems feasible in theory.