I think I’ve got a perfect use case for Hologram for a research project that is currently implemented with full Liveview for a rich UI. There’s a complex layout system in pure Elixir, fully independent from Liveview.
If I understand the docs correctly, what gets compiled to JS are the action function definitions. What are the limits there ? If I have fully qualified calls to a pure Elixir module that only uses the Elixir subset Hologram is capable of compiling, will this module be able to be compiled ?
My current architecture is fully decoupled from Liveview which only is the rendering and event handling pipeline. All the UI logic and definition is already pure.
Switching to Hologram would allow me to get a snappier UI and get rid of three hooks that are indispensable for fluid display.
Reading the compiler source, I get the impression that :
- Hologram builds a LUT of all available modules and converts everything to an internal IR
- Calls are traced from the Pages then from their
actions, meaning calling MyModule.foobar in an action will compile the whole of MyModule IR to JS wihtout further developer intervention
- JS is page-specific
- Unused functions get pruned
Is that right ? I did not find it in the docs, maybe a sample or two of fully qualified calls in Actions would clarify it for the next reader. If you wish, I can add a few examples.
3 Likes
Hi Lucas!
I’m really happy that you found a project where you can try Hologram! 
Your use case sounds like a perfect fit.
Your understanding is largely correct, with some additional details:
LUT: right!
Call tracing: Correct that calls are traced from pages, but the entry points aren’t just actions. For each page, Hologram traces from multiple entry points:
action/3 (user interactions)template/0 (rendering)__params__/0, __route__/0 (routing functions)- Plus similar functions for the layout module
When you call MyModule.foobar from any of these entry points, the entire reachable call graph gets included. There’s also special handling for:
- Components: Automatically includes
__props__/0, action/3, init/2, template/0
- Protocols: Includes all protocol implementations
- Structs: Includes
__struct__/0 and __struct__/1
- Apply calls: Can be determined for some cases
Page-specific JS: Correct - each page gets its own bundle with only the functions reachable from that page. Some commonly used functions go in the shared runtime bundle instead.
Function pruning: Yes, but it happens at the call graph level before transpilation - only reachable functions get transpiled to JavaScript at all.
Note that anything called from client-side actions gets compiled to JavaScript and runs in the browser. For server-side operations, you’d use commands instead of actions.
If you think something is unclear in the docs or should be added (like those examples you mentioned), I’m always open for such contributions
And don’t hesitate to reach out if something doesn’t work or if you find that some feature is missing - I’m here to help.
Looking forward to hearing how it goes with your research project!
2 Likes
Thank you for your in-depth response. I do not think the docs are unclear, but I have trouble with things that seem magical .
So when I read that Hologram does all the work of figuring it for you, a lot of questions come to my mind, like the perimeter covered, etc.
The site is already up and running with LiveView, a few things need to be finished, but I am unsatisfied of both resorting to JS commands (like toggling classes, etc) because it breaks the elm-like experience of LiveView, and of the latency of a few operations (because of server roundtrips).
I was planning to port the main view to Vue+channels to have fluid-er renders with declarative code while keeping some logic elixir-side. I think Hologram ticks the boxes of what we are trying to achieve. Given your answer I’ll pitch porting the public interactive side of the site to Hologram.
1 Like
That’s fantastic that you’ll be pitching Hologram for your project!
Since you mentioned the docs seem clear, I’ll keep them as simple as possible for now. That said, your feedback about wanting to understand the “magic” is really valuable. I’ve just added a task to the backlog to create a dedicated docs page explaining the compiler internals for folks who want to peek under the hood.
I’m also thinking some additional lifecycle information and maybe some simple diagrams on the Architecture page could help demystify how everything works together without introducing unwanted complexity.
3 Likes
