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
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!
Super cool. Just my initial thoughts from a brief glance at the website, but I like the ideas and architecture here and I think it'll probably represent an advancement in the space.
I do have one very surface level concern about the design and some disorganized thoughts about your comment here, so I guess I'll just dump all those at once for you.
Looking at "Actions and Commands" left me wondering "why?". The docs say:
Code execution is organized into two types of operations:
- Actions: client-side operations that run in the browser
- Commands: server-side operations for tasks like database access
Both can be triggered by user interactions, and they can trigger each other.
If they're both operations that can be triggered by user interaction and can freely trigger each other, and the only difference is where they run, why are they distinct framework concepts with distinct terms? Why aren't there just server actions and client actions? I know this is sorta just nitpicking at naming, but these decisions can't be easily changed later and they do affect how users approach and work with the model. I'm mostly expecting that they're actually more different than they seem at first and that justifies the strongly distinct categorizing and naming. Is that the case?
> While it requires Phoenix to run
I wasn't weirded out by it requiring Phoenix until you mentioned it here. Why "while"? This seems like it's competing in the liveview space and bringing isomorphism as its weapon, right? I wouldn't normally expect you to be replacing all of phoenix any more than I'd expect someone to supply their own fully in-house http client implementation. Are you mentioning it as a drawback here because there's something I'm missing that would make me concerned about phoenix being involved?
> we don't have 100% Elixir syntax coverage yet
Where is the boundary where I need to care about this? Can my entire app not use syntax that Hologram doesn't cover? Just the modules that `use` it? Just the parts that are transpiled to client-side JS like Actions (I had to go look up which term was the client-side one, by the way)? Even once you have full syntax coverage, I fear that I'm always going to need to be aware of when I'm actually writing "Hologram's pseudo-Elixir that has all the same syntax" so I can make decisions about rare in-the-weeds code that interacts with compiler stages or NIFs, or situations involving upgrading to a new version of Elixir that has new syntax that Hologram hasn't added yet. It's always going to leak a little.
> Bundle sizes are currently larger than they'll eventually be
> Compilation is taking its time because everything recompiles on any change. We had incremental compilation before, but I temporarily removed it
I'm glad you mentioned these. If I had tried out Hologram and found either of them without warning, I probably would have stopped paying attention to the project until someone explicitly came to me later and said "hey, you should try out Hologram again, it has reasonable bundle sizes and incremental comp now." But knowing that they're just temporarily missing in early releases and not fundamental drawbacks means I'm willing to invest time in learning it while those things get addressed.
Anyway, much congrats. Very cool looking project and I hope it takes off.
Thank you for this thorough analysis - these are definitely not disorganized thoughts! Let me address each point:
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 :)
I feel like your answer here is justifying the choice to use Phoenix, but my question was about the opposite. I would expect a project like this to use Phoenix in the first place, so I was wondering why you mentioned it as if it was something regrettable that you needed to be apologetic for.
Elixir syntax coverage:
Cool, sounds like the minimum possible infection. It does seem a little daunting knowing that any random library code that I transitively call from an Action will need to be transpile-able. If I call a utility function that uses a library that uses a library that implements some small-but-relevent part of itself as a NIF without me knowing, I assume that will fail to transpile and I'll be locked out from using that utility function until I swap out the dependency of a dependency with something transpiler-friendly. But thinking more about it, that probably doesn't come up much if Actions are just focused on simple operations. Out of curiosity, have you done any compatibility testing with Hologram's ability to correctly transpile and run code from major libraries? It might be good to publish a metric about this some day, like "Able to transpile 99.92% of the top 10,000 packages on Hex" with a little graph of how the number has improved over time or something. Many more important things first though, I'm sure.
> When using unsupported syntax, you'll get specific error messages in the JS console
In the JS console? Like at runtime? I don't just get them as build errors?
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.
I think it would be valuable to extract the JS transpiler into a standalone package. This would allow developers to leverage the transpiler's capabilities independently of the full Hologram framework.
Currently, the tight coupling with the framework limits adoption and potential contributions from developers who might be interested in just the transpiler functionality. By making it a separate package, you could:
- Increase adoption by allowing partial integration into existing projects
- Attract more contributors who specialize in transpiler development
- Make it easier to maintain and version independently
- Enable better testing in isolation
I'd love to contribute to the transpiler's development, but the current architecture makes it challenging without a full framework migration. Consider this a feature request that would make the tool more accessible to the wider JavaScript community.
10 comments
[ 3.0 ms ] story [ 36.3 ms ] threadFirst, 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://gi...
I do have one very surface level concern about the design and some disorganized thoughts about your comment here, so I guess I'll just dump all those at once for you.
Looking at "Actions and Commands" left me wondering "why?". The docs say:
If they're both operations that can be triggered by user interaction and can freely trigger each other, and the only difference is where they run, why are they distinct framework concepts with distinct terms? Why aren't there just server actions and client actions? I know this is sorta just nitpicking at naming, but these decisions can't be easily changed later and they do affect how users approach and work with the model. I'm mostly expecting that they're actually more different than they seem at first and that justifies the strongly distinct categorizing and naming. Is that the case?> While it requires Phoenix to run
I wasn't weirded out by it requiring Phoenix until you mentioned it here. Why "while"? This seems like it's competing in the liveview space and bringing isomorphism as its weapon, right? I wouldn't normally expect you to be replacing all of phoenix any more than I'd expect someone to supply their own fully in-house http client implementation. Are you mentioning it as a drawback here because there's something I'm missing that would make me concerned about phoenix being involved?
> we don't have 100% Elixir syntax coverage yet
Where is the boundary where I need to care about this? Can my entire app not use syntax that Hologram doesn't cover? Just the modules that `use` it? Just the parts that are transpiled to client-side JS like Actions (I had to go look up which term was the client-side one, by the way)? Even once you have full syntax coverage, I fear that I'm always going to need to be aware of when I'm actually writing "Hologram's pseudo-Elixir that has all the same syntax" so I can make decisions about rare in-the-weeds code that interacts with compiler stages or NIFs, or situations involving upgrading to a new version of Elixir that has new syntax that Hologram hasn't added yet. It's always going to leak a little.
> Bundle sizes are currently larger than they'll eventually be
> Compilation is taking its time because everything recompiles on any change. We had incremental compilation before, but I temporarily removed it
I'm glad you mentioned these. If I had tried out Hologram and found either of them without warning, I probably would have stopped paying attention to the project until someone explicitly came to me later and said "hey, you should try out Hologram again, it has reasonable bundle sizes and incremental comp now." But knowing that they're just temporarily missing in early releases and not fundamental drawbacks means I'm willing to invest time in learning it while those things get addressed.
Anyway, much congrats. Very cool looking project and I hope it takes off.
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 :)
Thanks, that's a satisfying justification.
Phoenix dependency:
I feel like your answer here is justifying the choice to use Phoenix, but my question was about the opposite. I would expect a project like this to use Phoenix in the first place, so I was wondering why you mentioned it as if it was something regrettable that you needed to be apologetic for.
Elixir syntax coverage:
Cool, sounds like the minimum possible infection. It does seem a little daunting knowing that any random library code that I transitively call from an Action will need to be transpile-able. If I call a utility function that uses a library that uses a library that implements some small-but-relevent part of itself as a NIF without me knowing, I assume that will fail to transpile and I'll be locked out from using that utility function until I swap out the dependency of a dependency with something transpiler-friendly. But thinking more about it, that probably doesn't come up much if Actions are just focused on simple operations. Out of curiosity, have you done any compatibility testing with Hologram's ability to correctly transpile and run code from major libraries? It might be good to publish a metric about this some day, like "Able to transpile 99.92% of the top 10,000 packages on Hex" with a little graph of how the number has improved over time or something. Many more important things first though, I'm sure.
> When using unsupported syntax, you'll get specific error messages in the JS console
In the JS console? Like at runtime? I don't just get them as build errors?
Bundle size and performance:
Yeah that's totally reasonable.
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.
Currently, the tight coupling with the framework limits adoption and potential contributions from developers who might be interested in just the transpiler functionality. By making it a separate package, you could:
I'd love to contribute to the transpiler's development, but the current architecture makes it challenging without a full framework migration. Consider this a feature request that would make the tool more accessible to the wider JavaScript community.