The purpose is efficient derived value management - automatic dependency tracking and selective memoization of computed values during re-renders.
But I think you’re absolutely right that we should think about this differently.
bartblast
Creator of Hologram
bartblast
Creator of Hologram
After thinking through this discussion more deeply, I realize it probably makes sense to take a step back and think about generic composability patterns first. The reactive patterns we’ve been discussing (derived values, memoization, etc.) would need to work within the constraints of whatever composability architecture we settle on.
React’s hooks are praised precisely because they enable composability – extracting and reusing stateful logic across components. If Hologram is going to have reactive patterns, they should compose just as elegantly (even if the implementation looks different due to Elixir’s functional nature).
I’ve just created a new thread specifically about composability patterns for Hologram
@garrison @jam @Lucassifoni @venkatd – I’d love to get your input on this broader composability question. The insights you’ve shared here have been incredibly valuable, and I think they’ll be just as relevant to thinking through how actions, state operations, and any eventual reactive patterns should compose together.
2
garrison
I don’t want to beat this topic to death but I wrote a lot of words here without providing any “visual” examples so I just want to rectify that before moving on. I’m intentionally using JS to avoid syntax bikeshedding.
Here is a function written in the “declarative” style:
function Dashboard({id}) {
const user = db.loadUser(id);
const name = user.first + ' ' + user.last;
const theme = user.settings.theme || 'light';
const summary = computeExpensiveSummary(user.subscriptions);
return <div class={theme}>Hello {name}, your summary: {summary}</div>;
}
Note that this is just code. It’s not intended to be any particular framework. This component would be re-run on each “render”, whatever that happens to mean. To make it faster, you might memoize a couple of lines:
- const user = db.loadUser(id);
+ const user = memoize(db.loadUser, [id]);
- const summary = computeExpensiveSummary(user.subscriptions);
+ const summary = memoize(computeExpensiveSummary, [user.subscriptions]);
Note that memoizing trivial things like the name or theme is probably not worth the overhead. This is why it’s important that memoization is a choice.
Imagine that instead of providing tools like memoize we wrote a framework where you can define a computation graph which handles it automatically:
function Dashboard(props) {
const graph = newGraph(props);
graph.addNode('user', ({id}) => { return db.loadUser(id) });
graph.addNode('name', ({user}) => { return user.first + ' ' + user.last });
graph.addNode('theme', ({user}) => { return user.settings.theme || 'light'});
graph.addNode('summary', ({user}) => { return computeExpensiveSummary(user.subscriptions) });
graph.addTemplate(({theme, name, summary}) => {
return <div class={theme}>Hello {name}, your summary is: {summary}</div>;
});
return graph;
}
I hope it’s clear why React did not opt for an API like this. Perhaps “inexpressive” was a poor choice of words, as I think you could technically make this “graph language” as expressive as React+Hooks. But it’s completely divorced from “actual code” in a way that makes me uncomfortable.
If nothing else at least I’ve finally found a way to describe why I don’t like Ecto.Multi lol
0
derek-zhou
I use Ecto.Multi all the time. Yes, it is not as expressive as Repo.tranact/2 but it is good enough for simple transactions, like 2~3 database ops. That’s 90% of all my database transactions. And it make potential foot gun impossible.
2
jam
Svelte 3 was glorious in terms of ergonomics. IME, it just worked and was a joy to work with.
Regarding the reasons cited for the move to Svelte 5 in that link:
- Writing svelte code outside of svelte components had a different syntax
This was a little annoying but unless you were writing a library, you’d rarely encounter it. - The compiler couldn’t see dependencies that were moved outside of the
$:
I never experienced this issue but I could see how this would be annoying, not a dealbreaker imo. - Signals
It seems Rich was heavily influenced, rightly or wrongly, by the performance Solid’s signals achieved. Svelte 3 was plenty fast and already more performant than React but Solid’s benchmarks were certainly much faster. IMO, Svelte lost some of its simplicity and value proposition in this transition but maybe it was the right move. Beyond the performance gains, they do seem to be an excellent pair for sync engines: https://youtu.be/YQT26cnCKqo?si=JKkfKgokzpK_0gTO
Bart can correct me if I’m wrong, but I suspect Hologram can avoid #2 with macro + call graph. Maybe #1 is a non-issue as well with macros. If Hologram’s ultimate vision is to be local-first, then maybe taking a hard look at #3 makes sense.
I think React’s approach was fine for its time but the state of the art has moved beyond that. I don’t think it’s a mistake that Solid, Vue, and Svelte have all converged to essentially the same solution with a different syntax.
2
garrison
I will again dodge the JS framework debate because I am only trying to share a perspective here and you should of course use whatever tools make you happy. I do not agree the SOTA has moved beyond React, though.
Yes, Svelte specifically converged towards runtime and away from compile-time, which was the important bit in context.
But if you feel you had a good experience with Svelte’s compile-time stuff then your perspective is of course appreciated (I have not used Svelte).
1
venkatd
I would suggest rephrase as:
”The purpose is reactivity - enabling automatic re-rendering when values change”
I deleted all mentions of implementation details to focus on the ideal API/DX.
(If we talk about memoization and such things in the problem statement, then we we allowing the implementation details to leak into the core design.)
Anyway, just a suggestion 
1
garrison
I don’t want to derail this into some sort of Ecto discussion (it was just an analogy).
What you may have noticed is that, in general, I am extremely avoidant of solutions that only handle simple cases. The reason, fundamentally, is that I think these solutions push you away from trying to do complex things, and I think that’s a big part of why “software” has become such a sad rigid husk of what it once was.
One little Ecto.Multi here, one little derived property there… no big deal.
But it’s death by a thousand cuts.
0
bartblast
Creator of Hologram
It depends on how the API will be designed, but generally, macros combined with a call graph will provide new possibilities in this regard.
2
bartblast
Creator of Hologram
I rephrased it to focus on “efficient derived value management” rather than “reactivity” - since Hologram already has component reactivity built-in, what this feature actually adds is smart management of derived values during those re-renders.
1