If I see this code in a new company I just joined I am quitting on day 1
Show HN: Frond – a frontend runtime for your app's dependency graph
11–20 of 21 posts
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#12How does Frond handle cyclic dependencies? Is cycle detection built into the runtime, or is it left to the developer?
[dead]
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#13I 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?
[flagged]
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#14What's the advantage of this over Jotai / atomic state / computed signals, which seems to require 10× less code with mostly the same benefits?
[flagged]
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#15type ProfileSpec = Frond.NodeSpec ; }; readonly result: Profile; }>; This begs to be its own DSL rather than TypeScript-type-meta-programming.
I generally agree. But FWIW it does feel fairly idiomatic in terms of code written with Effect/API design in the Effect ecosystem. (Disclaimer: my Effect usage so far has been mostly casual, this
observation is based on following the project and ecosystem pretty closely.)
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#16Interesting 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.
[dead]
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#17I 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…
I worked on a project a couple years back that would have benefited greatly from this approach. I look forward to giving it a spin when I have an opportunity.
I’m curious how much is React-specific, or rendering-specific for that matter. Context: the use case I had previously was “headless”, in the sense that state lifecycle was completely decoupled from rendering (with a thin library-agnostic bridge for presentation layer integration). Obviously that’s not a typical use case, I’m mainly curious because that design was partly driven by the kinds of inherent complexity that would nudge me to look for something like this in the first place.
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#18type ProfileSpec = Frond.NodeSpec ; }; readonly result: Profile; }>; This begs to be its own DSL rather than TypeScript-type-meta-programming.
[flagged]
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#19The library, the website, the submission title, and even the comments by the author here, all written with AI. Sloptastic!
Re: Show HN: Frond – a frontend runtime for your app's dependency graph
#20I 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…
I worked on a project a couple years back that would have benefited greatly from this approach. I look forward to giving it a spin when I have an opportunity. I’m curious how much is React-specific, or rendering-specific for that matter. Context: the use case I had previously was “headless”, in the sense that state lifecycle was completely decoupled from rendering (with a thin library-agnostic bridge for presentation…
[flagged]