112 karma · joined June 19, 2022
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!
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.
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.
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! :)
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.
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?
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.
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.
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
What you’ll get each month:
- Development milestones and progress updates
- New features being worked on
- Community discussions and highlights
- Insights into the framework’s direction
- Ecosystem news and updates
Think of it as your monthly check-in with the Hologram world - no need to piece together information from different places. Everything gets compiled into one convenient monthly update. Whether you’re already building with Hologram, considering it for future projects, or just want to stay in the loop on what I’m working on, this newsletter will keep you connected to our growing community.
Ready to join? Head over to https://hologram.page/newsletter to subscribe.
Looking forward to sharing this journey with you all!
The roadmap page provides a comprehensive overview of:
- Development Plan: Featuring both immediate priorities (before ElixirConf 2025) and medium-term goals (after ElixirConf), with features listed in planned order of implementation
- Feature Status: Detailed breakdown of what’s already implemented and what’s coming next
My immediate focus is on key improvements like optimizing client bitstring performance, implementing component-level rerendering, completing DOM events support, and adding cookies and sessions functionality.
The page also includes detailed status tables for various framework components, including the template engine, framework runtime, and Elixir client runtime features.
I hope this transparency helps the community understand where Hologram is headed and what to expect in the coming months. I welcome your feedback and contributions!
What features are you most excited about? Let me know in the comments!
I want to address some of the concerns raised in the comments:
Hologram is currently in early alpha stage. I released this version primarily to let developers experience Hologram's programming model and architecture.
The mobile navigation issues that several users reported were caused by a bug in Hologram's DOM patching mechanism (which is responsible for updating the page content during navigation) - this has since been fixed. However, you may still experience some lag on mobile devices. This is due to an early, temporary bitstring implementation that is very inefficient and causes performance issues with large templates (which are essentially huge strings). This is one of the areas that I'll be working on improving soon.
Some comments correctly pointed out that documentation is incomplete. You're absolutely right - I'm currently focusing heavily on improving the documentation. A more detailed explanation of what Hologram is and what to expect can be found in the announcement post on ElixirForum: https://elixirforum.com/t/hologram-an-isomorphic-elixir-web-...
Despite the issues with navigation and missing documentation that were highlighted in the discussion, many visitors still chose to star the project. Thank you very much for your support!
I'm committed to improving Hologram and addressing the concerns raised. The current version is just the beginning, and I appreciate both the criticism and encouragement from the community :)
I mentioned Phoenix as a dependency because some developers prefer other backend solutions like Ash Framework or Commanded (for CQRS/Event Sourcing), or may want to use Hologram with their existing non-Phoenix backends.
While Phoenix is currently a great foundation for Hologram (providing battle-tested HTTP, WebSocket, and PubSub capabilities), the long-term vision is to potentially make Hologram self-sufficient. This would give developers maximum flexibility in choosing their backend architecture.
That said, Phoenix remains an excellent choice and most Elixir web developers are already using it, making Hologram easy to adopt incrementally in existing Phoenix applications.
Elixir syntax coverage:
You are right, this shouldn't be an issue in practice due to Hologram's action/command distinction. Actions are meant for UI state updates and triggering commands, while commands handle things like database access, file I/O, and OS operations on the server side. We're actually quite close to 100% Elixir syntax compatibility. Process-related functionality isn't implemented yet, but the plan is to handle it initially using microtasks and Promises to provide semantically equivalent behavior and eventually use Web Workers for real parallelism. The key is that actions should remain focused on UI concerns, while commands handle the heavy lifting on the server side. This natural separation means you rarely encounter compatibility edge cases in practice.
> In the JS console? Like at runtime? I don't just get them as build errors?
Currently, syntax checks happen at runtime because Hologram doesn't perform dead code elimination for unused function heads. This means that even if your action code is valid, there might be unused function clauses in the same function that contain syntax we haven't implemented yet. Even if your code only calls one specific function head, all other heads of that function would still be included in the transpiled JavaScript.
Regarding Actions vs Commands:
The distinction serves several important purposes. Actions are synchronous and run in the browser, with access only to component state. They're expected to be reliable (barring code bugs). Commands, on the other hand, are asynchronous, may potentially fail (due to server/network issues), and have access to global server state (sessions, cookies, etc.). The naming choice, while perhaps not perfect (I'm not a native English speaker), was meant to reflect this fundamental difference - "action" suggesting immediacy, while "command" implies a remote procedure call. The inspiration came from Elm commands and Redux actions.
There's also a technical reason for the separation: Hologram builds a call graph and transpiles everything from actions (including all functions called by those actions, and all functions called by those functions, and so on) to JavaScript, making that code public. Having distinct terms helps developers maintain a clear mental model of what code will end up client-side.
Regarding Phoenix dependency:
To clarify - Hologram requires Phoenix (not Phoenix LiveView) specifically for its web server functionality and excellent channels/pubsub support. The long-term plan is to make Hologram available as a standalone app, though Phoenix will likely remain as a hidden dependency. This approach was chosen because: 1) it was more practical than building everything from scratch, and 2) most Elixir web developers already use Phoenix, making it easier to adopt Hologram gradually by starting with just 1-2 pages.
Regarding Elixir syntax coverage:
Currently, you only need to worry about syntax support for code in actions and functions called by actions. While this might sound simple, I understand it's more complex in practice. When using unsupported syntax, you'll get specific error messages in the JS console. The path to 100% syntax coverage is relatively straightforward for most features. The real challenge lies in parallelism - the primary plan is to implement this using web workers and dynamic JS chunks. If that approach proves unfeasible, the fallback plan is to use JS microtasks, though this would mean single-threaded execution. You can see the current implementation status in the roadmap here: https://github.com/bartblast/hologram/commit/4e4a141f514cd23... (this information will soon be available on the website here: https://hologram.page/docs/roadmap)
It's worth noting that actions typically involve relatively simple code - updating state, processing strings, handling events. More complex operations can be handled through server-side commands. While there might be cases for complex client-side processing (like file processing to reduce server load), these are rare. The ultimate goal is to avoid making developers think about syntax compatibility - I agree that having a "worse version of Elixir" would defeat the purpose.
Regarding bundle size and performance:
The current bundle size and performance metrics are temporary - expect them to improve by an order of magnitude. I chose to release early to gather feedback, as it's easier to make changes based on real-world usage.
Please don't hesitate to ask more questions or share your thoughts - your questions are incredibly valuable as they help me understand how developers perceive and interact with the project. This kind of feedback is essential for improving both the framework and its documentation :)
First, I owe you all an apology. There's a running joke among my friends that Hologram is like nuclear fusion or fully autonomous Tesla cars - always "coming very soon™" . While I've been telling many of you earlier dates, life had other plans.
I want to be transparent with you - the past two years have been incredibly challenging for me health-wise. I went through three surgeries, and from January to July, I was bedridden and unable to walk. It completely turned my life and work upside down. But I'm back now, stronger than ever, and ready to finally share Hologram with you!
What's Hologram?
Hologram is an isomorphic web framework that runs as your frontend layer in Elixir projects. While it requires Phoenix to run, you can use it with other backend solutions like Ash (HASH stack, anyone?). What makes it special? I’ve rebuilt it from the ground up with the ambitious goal of supporting 100% of Elixir syntax eventually.
Current Requirements
- Elixir 1.13.4 - 1.17.3
- OTP 22.3 - 27.1
(Other versions might work too, but they haven't been tested yet)
Let's Talk About the Current State
I want to be upfront about some current limitations and quirks:
1. While we don't have 100% Elixir syntax coverage yet, what's implemented lets you fully experience Hologram's programming model.
2. Live reloading is a bit moody right now - if you run into issues, try restarting the server or deleting the _build directory.
3. Bundle sizes are currently larger than they'll eventually be. The transpiled code is intentionally verbose for easier debugging.
4. Compilation is taking its time because everything recompiles on any change. We had incremental compilation before, but I temporarily removed it for better debugging.
5. Rendering is currently slower than planned due to full page rerenders on component state changes and a temporary bitstring implementation (yes, we're using integer arrays for bits right now).
What's Next?
I'm working on Hologram full-time for the next couple of months, focusing on:
- Addressing all the limitations mentioned above
- Implementing cookies and session support
- Porting the remaining Erlang functions to JS
- Adding tons of optimizations
I believe we'll be production-ready in a few months. I've spent the past months sharpening the saw, and now I'm all in!
How Can You Help?
The best help right now would be:
- Play with Hologram and report any bugs you find
- Share your feedback and experiences
- Stay tuned for coding tasks if you'd like to contribute directly
Got questions? Create a topic in our Hologram Forum: https://elixirforum.com/c/elixir-framework-forums/hologram-f... - I'm there daily, and your questions will help shape the documentation!
New Website!
Check out the new Hologram website: https://hologram.page/ (Desktop users, you might want to disable f.lux or similar tools for an hour to get the full experience)
Special Thanks
A massive thank you to everyone who reached out, showed interest, and cheered me on during this journey. And the most special thanks goes to Emilia - without you, I don't know how I would have made it through those bedridden months. You're amazing!
Spread the Word!
If you're excited about Hologram, please share this announcement with your network! Let's get more eyes on this project and build something amazing together.
Let's make web development in Elixir even more awesome!
---
P.S. Remember, this is just the beginning. The current quirks will be resolved soon, and I can't wait to see what you'll build with Hologram!
---
GitHub repo: https://github.com/bartblast/hologram
Website: https://hologram.page/