Wow, thank you! 
I’ll admit I overthink things constantly (just ask anyone who knows me), but at least it’s paying off in ways that matter. The cult status thing made me laugh though - let’s see if we can earn it!
bartblast
Creator of Hologram
3
bartblast
Creator of Hologram
Great insight, @jam! I completely agree with your framing of these opposing forces.
What’s interesting is that this tension probably maps quite directly to the macro question: #1 (complete control and explicitness) likely means minimal or no macros, while #2 (abstracting complexity) would lean heavily on macros.
This puts me in a tricky position. The Elixir community has historically been quite reluctant about macro-heavy APIs, and for good reason - explicitness is one of the core values that attracts people to Elixir in the first place. You can see this playing out with Ash Framework right now. It’s extremely macro-heavy, which lets it elegantly solve complex problems and reduce boilerplate dramatically. But that same characteristic creates polarized opinions: some developers swear by it because of the power and conciseness, while others can’t get past all those macros because they value explicitness and direct control.
If I go the macro route with Hologram, I’d likely deter a significant portion of Elixir developers who prioritize that explicitness. On the other hand, macros could eliminate a lot of the plumbing code and enable powerful compile-time analysis (which Hologram is uniquely positioned to leverage with its full call graph visibility).
The challenge is that Hologram’s North Star is developer experience (DX), but that means different things to different people in this context - and that’s exactly the problem. For some developers, great DX means explicitness and control: no magic, always clear what’s happening under the hood. For others, great DX means less boilerplate and cognitive load: abstractions that “just work” and let you focus on your application logic. Both are valid perspectives on what makes development enjoyable and productive.
So I can’t simply say “optimize for DX” - I need to decide which developer experience I’m optimizing for, knowing that choice will resonate strongly with some developers while alienating others.
The question is: does it even make sense to look for middle ground here? Or would that middle ground end up being the worst of both worlds - not explicit enough for the control-oriented developers, yet not ergonomic enough for those seeking simplicity? You’d potentially end up with something that doesn’t fully satisfy either group.
That said, there are counter-examples. Phoenix’s routing DSL and Plug’s pipeline builder are heavily macro-based, yet they’ve been widely accepted by the Elixir community. Maybe the key is whether the abstraction feels “worth it” - whether what you gain justifies the magic you’re accepting.
2
bartblast
Creator of Hologram
Just to clarify - Context isn’t really meant to be a store. It’s for avoiding prop drilling by letting components emit data that flows down to their children (who access it via props with from_context).
You could use Context at a page level as a “global store” and mutate it from anywhere by specifying the action target, but it would feel awkward/indirect. Context is component-bound, like React’s Context API. It’s not a decoupled store like Redux or Svelte stores.
I think what you’re describing - a truly decoupled store - is what @nikfp mentioned earlier too. I’d love to see what that would look like translated to Hologram if you have ideas!
1
nikfp
I’d like to take a stab at what the usage would look like on this, if at least to inform my opinions better. Let me cook a while and I’ll reply again with what I come up with.
3
bartblast
Creator of Hologram
This sounds interesting, would you mind sharing a simplified example of how you structure and compose these state modules?
0
jam
Yep, I agree. It’s funny too because I had the same two examples in mind (Ash and Plug / Router). IMO, it’s possible to keep macros to a minimum where they truly impact ergonomics for the better and offer some unique capabilities. I’d imagine there’s probably something on the order of a handful of macros max that would fall in that category.
1
garrison
Indeed, but it’s also the cost of getting things right. To again use React as an example, they essentially redesigned the entire thing (backend and frontend) with fiber/hooks after about 5 years. Post-hooks React may as well have been a new framework. Honestly, the fact that they got away with pretending it wasn’t a new framework is kinda hilarious. They did go out of their way to maintain backwards compatibility and interop, which is impressive. Presumably that was a business requirement.
I stand by what I said: you can either spend years on this stuff or copy the things that already work, recognizing that those things have been through years of evolution already and that is, in fact, why they work. Personally I choose to do a lot of copying because I don’t have infinite resources, but if you want to greenfield stuff I have nothing but respect for that. It just takes a while!
WRT the macro discussion, I don’t really have anything against macros. I do like the expressive power of a real programming language, but I think that’s actually orthogonal. My concern, which I have probably already expressed enough, is that the direction you’re proposing is equivalent to creating a new programming language in Hologram. It may not seem like it now, but I think it would end up that way. So the question becomes: is your programming language going to be good? And if you haven’t even accepted that you are rolling your own programming language, the answer is almost certainly going to be “no”. This is the curse of DSLs.
One more thing: Hologram’s raison d’etre as I understand it is to be “Elixir on the client”. If you lean too heavily into a DSL, even if that DSL is good you are working against that mission. That could be a branding problem.
2
garrison
Can you explain in more detail what you mean with the call graph stuff? Is the call graph static? What happens if I try to make a function call dynamically?
0
Lucassifoni
I fear it isn’t, my work is deep in the depths of what I call officetech or boringtech 
.
Most of my work involves tools that produce book-like or slides-like material, with a data structure that is tree-like, but their physical projection is a flat list of pages in the end. Or a list / tree of such documents, but a single document ends up a flat list. Backend state is nice to interact with programmatically and frontend state is nice to interact with from an user’s point of view. Both are linked but very different. Users acting on the tree model would be an horrible UX and interacting with the flat model programmatically would be horrible DX.
So it simply is deeply nested structures of very simple Elixir structs + their management functions. The UI is a function of the tree structure by the frontend framework (Vue* in my case - a bit of a regret). The frontend sends events to the backend through websockets, applies optimistic updates, then applies partial or full updates from the backend’s answers, to the projected state.
Re : composition, I liked the spreadsheet-like example I shared in the other thread because of an explicit composition operation where a sub-graph’s outputs could become a wider graph’s inputs. I will see if that stands the test of time and resists to feeding a bigger UI.
To summarize it, I am posting in those threads because I am looking for ideas about interesting state managment and transition patterns, fully isolated from the UI.
Sorry, it’s a bit confused, because I am actively thinking about different re-structures and a bit “in the depths” of it these days.
(*Well Vue or Liveview depending on acceptable latency)
1
bartblast
Creator of Hologram
I appreciate the perspective, but I want to clarify - I’m not choosing to greenfield for its own sake. The reality is I can’t simply copy React or Vue patterns because they’re deeply tied to mutable, object-oriented architectures.
React Server Components (Next.js) might seem relevant, but that architecture is ridiculously complex - it requires distinguishing “use client” vs server components, managing serialization boundaries, handling two separate component models, and coordinating between them. It’s essentially a retrofit onto React’s client-centric design.
Take React hooks specifically as an example of patterns that don’t translate:
-
Architectural mismatch - Hooks rely on hidden mutable state in React’s fiber tree. The render function pretends to be pure (
props → JSX), but secretly accesses and mutates global framework state. In Elixir, you’d need explicit Agents/GenServers, making this hidden complexity visible and fundamentally changing the architecture. -
Rules of Hooks - Call order dependency (can’t use hooks conditionally) exists because React identifies hooks by position, not semantically. This fights against natural Elixir pattern matching and control flow.
-
Testing complexity - You can’t just call a component function and test it. You need
act()wrappers to coordinate async updates, React Testing Library to provide runtime context, and complex state setup just to test what should be simple render logic. -
Initialization vs. rendering separation - Hologram explicitly separates
init()(runs once to set up initial state) fromtemplate()(a pure function that transforms state/props into DOM). React hooks deliberately interleave these - your component function runs on every render, re-executing hook initialization logic that relies on call-order tracking to “remember” state. This interleaving is core to the hooks design, but it’s fundamentally incompatible with Hologram’s architecture where state is explicit data, not implicit framework-tracked position.
I was genuinely hoping someone would enlighten me on how to elegantly port these patterns while addressing these concerns. But the more I examine it, the more it seems like forcing a square peg into a round hole. Patterns that work in JavaScript with mutable objects don’t translate cleanly to Elixir’s immutable, functional paradigm.
3