bruh VS starfx

The key is topological sorting of a dependency graph. This can be done implicitly by storing a reactive variable node’s depth once it is created, and just making sure that updates are enqueued in separate queues per depth.

I have a somewhat small implementation that transparently batches updates with queueMicrotask in this library (bruh): https://github.com/Technical-Source/bruh/blob/a829af9df9405b...

If you have any questions, you can ask here now or in the discussions tab in the github page.

Ah! A real criticism of FE development, I agree with your problem statement.

When you jump into the world of single-page applications, things get complex pretty quickly, because the use case for needing an SPA pushes the web app into a full desktop application.

Ultimately, for a highly interactive and dynamic "desktop-class" user experience, there is added complexity. I think that's why so much movement within the FE world has moved away from "SPA for everything" and into these mixed dynamic apps. Islands, React Server Components, NextJS, they all help create a middleground between a document-based website with no dynamic elements with a full blown desktop app experience. They all have real tradeoffs, in particular adding an entirely new backend service to serve the front end.

For many projects, react + react-query is probably enough.

Having said that, my argument from https://bower.sh/dogma-of-restful-api still stands: when you build an API that is RESTful (1:1 mapping between endpoint and entity) you are unknowingly pushing the complexity of data synchronization to the FE, which requires a well thought out ETL pipeline.

This probably doesn't help my case but I've been building a simplified middle-layer for react to bridge the gap between react-query and full blown SPA: https://starfx.bower.sh

`redux-saga` maintainer here.

I've been using `effection` to build a replacement for `redux-saga` over at https://github.com/neurosnap/starfx

Effection has demonstrated to me how truly powerful delimited continuations are and why structured concurrency is an incredible asset for anything that requires async flow control -- basically everything in TS/JS.

I know sometimes it's hard to imagine why someone would need structured concurrency or care about delimited continuations for a front-end application, but this is a game changer in terms of expressing async flow control.

Some things to note about Effection:

- API surface area is small https://github.com/thefrontside/effection/issues/851

- It tries to stay as close to JS constructs as possible so it will feel very familiar

- Resource cleanup is automatic (when a function passes out of scope all descendent tasks are shut down automatically)

- End-user doesn't need to think about delimited continuations

The only leap users need to "deal with" coming from async/await is the syntax.

    import { main, call } from "effection";

- https://github.com/thefrontside/continuation

- https://github.com/thefrontside/effection/tree/v3

- https://github.com/neurosnap/starfx

The last one intends to replace redux-saga using DCs.

Here’s a presentation I gave recently talking about DCs in typescript: https://youtu.be/uRbqLGj_6mI?si=XI0JNMKMoO2VHMvM

A couple of us have been experimenting with deliminited continuations and I think it’s gonna take off soon:

https://youtu.be/uRbqLGj_6mI?si=kgKKjpCnehJ9bpIG

https://github.com/neurosnap/starfx

I feel the same way which is why I decided to help maintain the project. Async flow control is very tricky even in js–land. Having watchers live inside of a while-loop is a powerful construct that lends itself to interest flow control patterns.

I'm also in the process of rebuilding redux-saga but without the redux part: https://github.com/neurosnap/starfx

It's still in alpha stage, but it is very reminiscent of redux-saga.