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?

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.

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.