Hologram can be used alongside LiveView in the same Phoenix application. You can have some pages running in LiveView and others in Hologram - they can coexist peacefully.

However, I don’t plan to work on direct Hologram/LiveView integration (like embedding Hologram components within LiveView pages or vice versa). This would introduce significant complexity and several drawbacks, including maintenance burden, architecture lock-in, conflicting paradigms, performance overhead, and others.

If you need to stick with LiveView for any reason (time constraints, existing codebase, etc.), you can always gradually migrate specific pages to Hologram when it aligns with your project’s requirements. This approach gives you the flexibility to use both frameworks without the complexity of trying to make them work together. Additionally, I plan to start working on a companion UI components library soon, which should significantly reduce the time investment needed to build interfaces with Hologram and make migration easier.

The key insight was that every microsecond matters when you’re building a framework that needs to handle real-time interactions, render at least 60 FPS, and work with transpiled code using boxed types. I systematically profiled and optimized each layer - from the lowest-level bitstring operations up through the highest-level user interactions.

For profiling and benchmarking, I used a multi-tool approach:

• Benchee for comprehensive Elixir performance testing
• Custom JavaScript benchmarking scripts using process.hrtime() for precise timing
• Chrome DevTools Performance Profiler for detailed client-side analysis

The JavaScript JIT compilation made it even more tricky, because you’ll see much different results for cold vs warm vs hot code. For the Elixir part, I was mainly optimizing the compiler, so the tricky part was balancing different project conditions - e.g., different characteristics depending on the call graph structure, module complexity, and compilation patterns.

It’s been quite a journey! The performance improvements were the result of countless hours of profiling, benchmarking, and iterative optimization. It was a very repetitive process, but strangely satisfying when you managed to squeeze out performance gains here and there

Video courses are coming soon in about 2-3 weeks.

The demo is a part of the website code which is currently private, but here’s the most important code:

init/3 (state initialization) and actions (event handling):

def init(_params, component, _server) do
  put_state(component, drawing?: false, path: "")
end

def action(:clear_canvas, _params, component) do
  put_state(component, drawing?: false, path: "")
end

def action(:draw_move, params, %{state: %{drawing?: true}} = component) do
  new_path = component.state.path <> " L #{params.event.offset_x} #{params.event.offset_y}"
  put_state(component, :path, new_path)
end

def action(:draw_move, _params, component) do
  component
end

def action(:start_drawing, params, component) do
  new_path = component.state.path <> " M #{params.event.offset_x} #{params.event.offset_y}"
  put_state(component, drawing?: true, path: new_path)
end

def action(:stop_drawing, _params, component) do
  put_state(component, :drawing?, false)
end

and the most important part of the template:

(...)
  <button $click="clear_canvas" class={Button.class(:md)}>Clear</button>
</div>
<svg 
  class="bg-[#0F1014] cursor-crosshair border border-[#363636] rounded w-full h-[70vh]"
  style="touch-action: none;"
  $pointer_down="start_drawing"
  $pointer_move="draw_move"
  $pointer_up="stop_drawing"
  $pointer_cancel="stop_drawing"
>
  <path d={@path} stroke="#C2BBD3" stroke-width="2" fill="none" />
</svg>

While you’re definitely right that Hologram isn’t production-ready yet, I think you’re painting a bit too dramatic a picture here Yes, there are missing features, but what’s left is straightforward. The complex architectural work is done: the runtime, component system, and core primitives are solid.

My focus now is on creating escape hatches so developers don’t get stuck waiting for releases. I’ll prioritize features that users can’t implement themselves:

• JS Interop - for when you need to interface with existing JavaScript
• Essential DOM events - including window-level and keyboard events
• Error handling - can’t really work around this yourself
• Server-to-client events - including PubSub abstraction for real-time features
• Action timing/delays - enables things like tick events for games (since we don’t have client processes yet)
• Command failure handling - proper error states and recovery
• Action scheduling from within init/3 - scheduling actions from init/3 functions in pages/components

Everything else can be easily worked around (provided the features listed above are implemented). Missing an Erlang function? Just use a server command - you’ll get the same performance characteristics as LiveView.

To put this in perspective: these features in total are less complexity than I put into just the bitstring rewrite in v0.5.0 (implementation | tests). The foundation is solid; now it’s about filling in the practical gaps.

I think we’re closer to real usability than it might seem - worth starting to experiment now with migration in mind!

Random implementation detail, but I’d like to make a library for transpiling regexes from Elixir → js and Elixir → Postgresql at some point, that would be a subset (a growing subset over time) of Elixir’s regex capabilities. Might be useful when you get to =~ operators etc.