Stoids

As someone who created those horrifying RxJS monstrosities, I agree with most of this, which is why I caveated my concerns. Tanstack Query simplified a lot of these issues—separating server state and caching from client side state was a huge boost. I’m mostly coming from the perspective of someone who just inherited a Jotai code base with 200+ atoms and trying to wrap my head around it. Any library poorly used can lead to a mess though, so not going to claim it’s a problem inherent to all atom based approaches.

Most UIs I've written in my career benefit from being modeled as FSMs. While I see the value proposition of the atom-based approaches, especially for basic applications, I can't help but become a bit hesitant about their scalability long-term on large teams. Part of the reason the very dogmatic Redux approach of a event dispatching + single store of truth caught on so quickly was because a lot of us had felt the pain of two-way data binding / global state with event listeners in Angular 1. I distinctly remember the horror of debugging digest loops (scope.$$phase memories) and being completely lost in the unstructured data flow. What made for a great demo became a nightmare at scale.

There's nothing stopping people from using these atom-based libraries to build more robust abstractions, but from my professional experience I tend to just see global getters and setters with useEffects / lifecycle method of your frameworks choice as a side effect sync.

Maybe my instincts are off here though and I am overly cautious. I love XState but the learning curve is rather massive and getting buy in from other team members is hard when the DX of the atom approach is so nice.

I feel like state "management" and reactivity performance are talked about a lot, when ultimately state orchestration is where I see things fall over the most.

We aren’t good at creating software systems from reliable and knowable components. A bit skeptical that the future of software is making a Rube Goldberg machine of black box inter-LLM communication.

I think going all-in on Effect in its current state is not something I'd do. However there's a subset of its functionality that I'm currently replicating with a bunch of different libraries: ts-pattern, zod, some lightweight result / option wrapper like ts-belt, etc. Pretty much trying to pretend I'm writing ML / OCaml. Having those all in one package is quite convenient. Add in TypeScript's the much needed story around retry / observability / error handling—I see why people lean into it.

Having experience with ZIO / FP in Scala, I'm a bit biased in seeing the value of Effect systems as a whole, but taking on the burden of explaining that mental model to team members and future maintainers is a big cost for most teams.

The fragmentation around runtime validation libraries is pretty crazy. The fact that half these comments mention some alternative library that mimics almost the exact API of Zod illustrates that.

It is filling a necessary shortcoming in the gradual typing of TypeScript, and using validator schema types to power other APIs generic inference is powerful. I am optimistic about an obvious leader emerging, or at least a better story about swapping between them more easily, but a bit annoying when trying to pick one to settle on for work that I have confidence in. That being said, Zod seems like the community favorite at the moment.

I do consulting for a few restaurants, and despite my experience building full-stack web applications, I find myself reaching for Excel for most of my deliverables. These are "applications" that "non-technical" restaurant operators need to be comfortable in. Having a sheet where they paste in some data and get their needed output has required the least amount of continued maintenance and training. They can drag the file around in Dropbox / Google Drive and that works for them.

I still try to "engineer" to the best of my ability—separating raw input from derived data from configuration, data normalization, etc. With Lambda functions in Excel now, I kinda just pretend I'm writing Lisp in an FRP editor / runtime environment. The ETL tools with PowerQuery are quite good for the scale that these restaurants operate at.

Hard for me to turn off my brain in my full-time job when I am tasked with poorly recreating a feature that Excel nailed years ago.

Do you have any favorite resources (can be books, courses, blog posts) that teach with this approach from? I have been diving more into 3D and the shortcomings in my mathematical background are starting to show.

Thanks for the link! Hadn't seen that release, looks promising. I think this could definitely work for some of our newer apps that haven't fully bought into GraphQL yet. Not sure if the loader / action prop callbacks will be sufficient when you start getting into more complicated GraphQL use cases around caching. Haven't played with it though, so might be wrong! Good to see that these will already be in place for the community to leverage.

Thanks for the links! Will certainly check them out, might even send me down memory lane a bit when I was first reading about these. Would love a full-fledged recap at some point—it's really interesting getting insight into the the internal mechanics of the problems my UI framework solves for me in my day-to-day. I always come away feeling more informed when you write something, but you've earned a long break after this release, so no pressure!

I hear you on the data fetching and always appreciate your teams' cautious approach. It gives me a lot of confidence in the APIs you all end up landing on, and I appreciate the focus on backwards compatibility and incremental upgrading as opposed to shipping out the first iteration of a cool idea that comes to mind. I know just enough about React to probably shoot myself in the foot with this type of stuff, but add in the idea of concurrency and all that likely falls over.

I think the story here with Relay and GraphQL is really awesome. I hope the Relay team has an article in the future showing off some of the possibilities—I think it makes a really strong argument for itself in conjunction with these features, even taking into account the restrictions you mention. Showing how some of these features flesh out in a more complete framework would be helpful in framing them in a vacuum. Or maybe I'll stop complaining and explore and write something myself!

Congratulations to the React team on the release! I've kept up somewhat with the development of these features since Dan first introduced some of the ideas at JSConf 3 years ago. It's interesting to see how the APIs have changed over time—I'm sure as a result of some tough lessons learned at Facebook.

As someone who has worked on large React projects worked on by multiple teams, I can see a lot of the value proposition being delivered in this release. I can already think of many places where I'll want to slot in the transition API.

I'm curious if the SuspenseList API is making the cut here or if it's still on the roadmap? I played with it a while back and thought it was very cool, albeit slightly niche perhaps.

The only part that's a bit of a bummer is the recommendation on using suspense for data fetching. I'm already itching to get rid of lots of if (loading) {} code that plagues many of our components and makes orchestration and re-use of them a bit more painful than we'd like. I see lots of power in the idea of suspense as a way to orchestrate various generic async operations, but it feels like they don't want us to build solutions on this abstraction unless we buy into some opinionated framework. I can't really tell my team "let's use remix now lol".

All that being said this is a tremendous step forward and I'm looking forward to seeing what problems the React team tackles next.