bartblast
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/