Show HN: Frond – a frontend runtime for your app's dependency graph
1–10 of 21 posts
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#2I built Frond, a frontend runtime that makes your app's dependency graph explicit instead of leaving it scattered across provider order, enabled: user && api.ready guards, and logout teardown scripts.
The shape: your app is a graph of nodes — services, resources, screens. Each node declares its dependencies, how it's acquired, how it's cancelled, and how it's released, all in one place. The runtime resolves them in dependency order and tracks readiness, so React stays a renderer — it consumes a node that's already ready (useNode suspends until it is) instead of re-deriving that logic inside components.
Two engines run underneath. Effect handles the async work — execution guarantees, cleanup correctness, cancellation, and typed error channels. MobX handles state — granular observable state and live updates. You declare a node's dependencies, acquire, and release; Frond runs the rest on those two.
It's v0 and the API will still move.
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#3[flagged]
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#4What's the advantage of this over Jotai / atomic state / computed signals, which seems to require 10× less code with mostly the same benefits?
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#5Interesting approach.The lifecycle management and teardown story seems to be the main differentiator rather than state itself.How does Frond compare to Effect's Layer system? Is it essentially bringing Layer-like dependency graphs into the React runtime?
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#6What's the advantage of this over Jotai / atomic state / computed signals, which seems to require 10× less code with mostly the same benefits?
[dead]
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#7Interesting approach.The lifecycle management and teardown story seems to be the main differentiator rather than state itself.How does Frond compare to Effect's Layer system? Is it essentially bringing Layer-like dependency graphs into the React runtime?
I understand it like events + state machine type of approach.
Reacts only renders and emits events, and I guess the state machine imperatively will dictate to react what to render according to the result of executing whatever is in the state transition.
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#8 type ProfileSpec = Frond.NodeSpec;
};
readonly result: Profile;
}>;
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#9I built Frond, a frontend runtime that makes your app's dependency graph explicit instead of leaving it scattered across provider order, enabled: user && api.ready guards, and logout teardown scripts. The shape: your app is a graph of nodes — services, resources, screens. Each node declares its dependencies, how it's acquired, how it's cancelled, and how it's released, all in one place. The runtime resolves them in d…
How opinionated is Frond? Could someone adopt it incrementally, or does it need to own the entire application's dependency graph?
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#10How does Frond handle cyclic dependencies? Is cycle detection built into the runtime, or is it left to the developer?