I still don’t know where this fits with Phoenix/liveview/bandit. Does it replace them? Why and to what end? Am I to use it as a companion? For which parts?
In other words, which problems do I need to have to appreciate how cool this is?
LiveView: Renders UI updates on the server and sends them to the client.
Hologram: Transpiles your Elixir UI code to JavaScript that runs entirely in the browser.
You'll appreciate Hologram when you want to avoid LiveView's latency. For example:
- Instantaneous UI interactions without client-server roundtrips
- Real-time interactions like smooth drawing, drag-and-drop, or complex animations
- Offline-capable applications that work without constant server communication
- Reduced server load since UI logic runs client-side
If you need truly responsive client-side interactions or want to reduce server roundtrips, that's where Hologram shines. It's the same Elixir developer experience, but with client-side performance characteristics. Think of it as "LiveView for when you need the UI to feel like a native app.
Note: Currently Hologram requires Phoenix, but in the future you'll be able to run it as a standalone framework.
Web devs are in full control of their whole stack (excluding the browser where you occasionally need to account for incompatibilities), have to maintain only one version of the app (no upgrade needed on client-side), are not constrained by the platform owner's policies (app store tax).
Yes, it's more limited than native technologies in other ways, so it's not an answer for every problem.
Distribution aside, its more likely you only know web languages and THATs why youre coding your project on the web stack. Pick the best tool for the job
Your hammer/nail analogy actually supports the case for Hologram: if Elixir is genuinely a superior tool for building systems, why shouldn't we extend that tool to work client-side too?
Native development absolutely has its place, and for many use cases it's the right choice. But there are legitimate scenarios where you want the reach and deployment characteristics of the web platform combined with client-side performance. That's exactly what Hologram provides - it transpiles your Elixir UI code to JavaScript that runs in the browser, giving you instant interactions without server roundtrips while keeping the language and paradigms you prefer.
Binary distribution isn't technically hard in 2025, you're right. But "not technically hard" isn't the same as "optimal for every use case." Sometimes you genuinely want instant deployment, universal accessibility, and the ability to update your application without user intervention. Different tools for different jobs.
I'd actually love to hear what you think about Hologram's transpilation approach specifically - writing Elixir UI code that gets converted to JavaScript for client-side execution. Does that change the equation at all from your perspective?
Here are the key advantages of web clients beyond distribution:
Instant updates - Push a new version and every user gets it immediately. No app store approval process, no waiting for users to update, no supporting multiple versions in the wild.
Universal accessibility - Works on any device with a browser. Your grandmother's old Windows laptop, your coworker's Chromebook, someone's phone - all access the same application without platform-specific builds.
Zero installation friction - Users can try your application instantly by clicking a link. No download, install, permissions, or disk space considerations.
Sandboxed security model - Browsers provide built-in security isolation. Users trust clicking web links more than downloading and running executables.
Seamless integration - Easy linking, sharing, bookmarking. Users can send a direct link to a specific state of your application.
Lower development/maintenance overhead - One codebase, one deployment pipeline, one set of bugs to fix. Compare that to maintaining separate iOS, Android, Windows, Mac, and Linux builds.
Built-in networking - HTTP/WebSocket APIs are first-class citizens. No need to bundle networking libraries or worry about firewall configurations.
That said, native absolutely wins on performance, system integration, and offline capabilities. It's genuinely about picking the right tool. For Hologram specifically, we're trying to get you closer to native performance while keeping these web deployment advantages - best of both worlds for certain use cases.
Elixir brings some incredible advantages: the Actor model for handling concurrency, fault tolerance, pattern matching, functional programming paradigms, and honestly just a really enjoyable developer experience. When you're already building your backend in Elixir and loving it, being able to use the same language, mental models, and tooling for the frontend is hugely appealing.
It's less about avoiding native development and more about 'I already know and love this language - why not use it everywhere?' Similar to how JavaScript developers felt when Node.js let them use JS on the backend, or how Swift developers felt when SwiftUI came along.
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.
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.
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.
Can Hologram sit alongside the existing routes of a Phoenix app?
This is actually a really nice migration path - you don't have to rewrite your entire app. You can gradually move specific features to Hologram where offline support or instant responsiveness matters most, while keeping LiveView for parts where server-side rendering is enough.
For your offline/low bandwidth requirements specifically, Hologram is perfect because once the JavaScript is loaded, all the UI logic runs locally. No more waiting for server roundtrips on every interaction, and the app continues working even when connectivity is spotty.
One thing that's unclear to me in how I might manage this "side-by-side coexistence": how you manage potential route conflicts, e.g., You have a Hologram "page" that defines `route "/hello-world"`, and the Phoenix application router.ex also defines a route, `live "/hello-world', MyApp.HellowWorld, :index`.
I could imagine the lack of a central router may be offset through conventions of how you organize pages (perhaps a directory-based-routing convention). I saw in the Installation section that it's common to organize under `app/`, and `app/pages`. Maybe an expansion on best practices for larger project organization, and how you keep Hologram routes straight, would be interesting to other people as well.
Regardless, I've just started dipping my toes in the elixir and phoenix ecosystem about 3 months ago, and it's been a real joy. I'm throwing every hobby project I can think of at it to learn more. I'll give hologram a spin -- thanks again for such clear documentation.
You raise an excellent point about route conflicts. I'm actually thinking about detecting these at compilation time and throwing an error with details about which routes are conflicting and where they're defined. That should catch these issues early and make them easy to resolve.
The best practices guide is definitely a great idea and something I've been thinking about. I already have some ideas regarding project organization and routing conventions, but I want to ship a few more core features first before diving deep into that documentation. Hologram really obsesses over developer experience, and comprehensive docs are a big part of that :)
It's awesome to hear you're enjoying the Elixir/Phoenix ecosystem! Three months in and already exploring different frameworks shows great curiosity. I'd love to hear how your experience goes with Hologram when you give it a spin. Thanks again for reading through all the docs and providing such thoughtful feedback! :)
The initial page load isn't impressive, though: Google's PageSpeed Insights indicates a 100+kb runtime with lots of unused JavaScript initially, resulting in a LCP of 1.5s (results will vary, of course). I wonder how much of the JavaScript is simply code that stores the website pages, haven't had the time to look at this in detail yet.
For a docs website, that's excessive and bloated; it'd be much better to just deliver no JS and provide HTML with prefetching rules and cache headers (which would also provide instant navigation and offline support).
I'm happy they made the docs website with it, though, to dogfeed and showcase it.
The 1.5s LCP you're seeing is quite different from what I'm observing. Performance can vary significantly based on location, network conditions, and device capabilities, so perhaps that's contributing to the difference in our results?
It's also possible that different pages have different performance characteristics depending on their content complexity and the navigation structure. Could you share which specific page you tested? That would help me understand the discrepancy better.
Regarding the runtime size - it hasn't been optimized at all yet, so I expect it will be much smaller in the future. I wouldn't be surprised if we can reduce it by a few times through proper optimization.
You're absolutely right that for a pure documentation site, a no-JS approach with prefetching would be lighter. The Hologram docs site is indeed dogfooding - I wanted to showcase the framework's capabilities and stress-test it with real-world usage, even if it means some overhead for this particular use case.
The goal was to demonstrate the instant navigation experience you mentioned, plus features like client-side search and interactive examples in the future that benefit from the stateful client-side architecture.
Thanks for taking the time to test the site and provide this feedback!
The page I tested is the one linked here in HN (the announcement)! I guess I should've referenced the PageSpeed Insights URL [0]. I hope you can get your bundle sizes smaller in the next versions, because honestly, from my first look (not very in-depth, of course), it's the only thing that's not very attractive about it. Likewise, I keep in mind, though, that most web frameworks nowadays ship very large bundles to achieve hydration and client-side routing.
I'm excited to see future updates to this project!
[0]: https://pagespeed.web.dev/analysis/https-hologram-page-blog-...
I do notice that the report shows 104 KiB transfer size for the runtime bundle, which I think is actually a relatively reasonable result for a modern web framework, though there's certainly room for improvement. The bundle size will definitely decrease substantially in future versions as I focus on optimization.
Also worth noting that the bundles aren't being cached properly yet, which is another thing the framework should handle automatically - that alone would make a significant difference for repeat visits. This one's an easy fix though.
Everything you've mentioned is noted and will be addressed! Thanks again for taking the time to run the analysis and share the specific results - having concrete data like this is really valuable for prioritizing improvements.
I see that you've been focusing on the performance aspect but I see a big benefit with the offline first use-case.
It would be nice to have built-in support for syncing any changes when the client comes back online as it would remove the biggest issue with LiveView based websites (that they stop functioning if you lose connection).
For example, a simple todo list where you can check off items offline and when you go online they're sent to the server?
> Hologram is a full-stack isomorphic Elixir web framework that runs on top of Phoenix. It lets developers create dynamic, interactive web applications entirely in Elixir. Through intelligent code analysis and transformation, Hologram converts the necessary parts of your Elixir code into JavaScript, delivering modern frontend functionality without requiring any JavaScript frameworks or direct JavaScript coding.
bartblast•3d ago
Key highlights:
- Complete bitstring rewrite with ~50x rendering speed improvements!
- Comprehensive session and cookie management
- Live reload functionality for enhanced DX
- Incremental compilation (2x-10x faster builds)
- New pointer and mouse move events
- HTTP-based transport layer
- CRDT support for future distributed features
Full release notes: https://hologram.page/blog/hologram-v0-5-0-released
Check out the SVG Drawing Demo that showcases smooth, responsive drawing using the new pointer move events - it really demonstrates the performance leap! https://hologram.page/demos/svg-drawing
With over 950 commits since v0.4.0, this release delivers significant architectural enhancements while maintaining the unique developer experience that makes Hologram special.
Special thanks to my current GitHub sponsors: @D4no0, @Lucassifoni, and @sodapopcan!
Support Hologram’s development: If you’d like to help accelerate Hologram’s growth and make releases like this possible, consider becoming a GitHub sponsor. Every contribution helps dedicate more time to new features and community support! https://github.com/sponsors/bartblast
Stay in the loop: Don’t miss future updates! Subscribe to the Hologram Newsletter for monthly development milestones, ecosystem news, and community insights delivered straight to your inbox. https://hologram.page/newsletter
agos•11h ago
bartblast•9h ago
And this is just the beginning - I'm working on component-level selective rendering that should make things an order of magnitude faster still. Instead of re-rendering the entire page, only the specific components that actually changed will be updated.
It's exciting to see the performance gains become so noticeable in real usage. The hamburger menu responsiveness is exactly the kind of instant interaction that Hologram is designed to enable! :)