Well. This is nifty. I currently work on a full stack web application, and having the same language everywhere is really nice. This is that, but for Elixir. I’m definitely giving this a tire-kick when I have some spare time.

▲

bartblast 4 days ago | parent | next [-]

Thanks for the interest! That's exactly the vision - having Elixir everywhere in the stack is incredibly powerful. I'm actually planning to expand Hologram beyond just web applications. The eventual goal is to make Hologram a cross-platform development platform, so you could potentially target also mobile and desktop while staying in the Elixir ecosystem. Still early days, but the foundation I'm building with the web framework is designed with that broader vision in mind. Would love to hear your thoughts after you give it a try!

▲

gchamonlive 4 days ago | parent | prev [-]

Don't know if this was your intent, but you make it sound like it's only now, with hologram, that elixir's got superpowers and can be used both in front- and backend. However Phoenix Liveview has been around for a while.

▲

bartblast 4 days ago | parent [-]

Phoenix LiveView is absolutely fantastic for many use cases and has been a game-changer for the Elixir ecosystem. I have tremendous respect for what the Phoenix team has built.

The key difference with Hologram is that it transpiles Elixir code to JavaScript that runs directly in the browser, eliminating server round-trips entirely. So while LiveView uses websockets to update the DOM from the server, Hologram gives you true client-side execution with zero latency for interactions.

▲

gchamonlive 4 days ago | parent [-]

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.

▲

bartblast 4 days ago | parent [-]

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.

	▲	gchamonlive 4 days ago \| parent [-]
		Excellent response! Thanks for your effort!