Proposal link

It looks a lot like React hooks, and that's intentional as it's a partial inspiration, but I've extended that somewhat and gave it additional semantics with the goal to make it much more broadly useful, fulfilling many of the same functions as Backbone and Redux by making it a generic serializable state store rather than hard-coded to any particular pattern. (You can see this in action with my counters.)

1 Like

This seems like a very interesting idea, and it's well thought out - I'm intrigued by its potential.

You've discussed a bit about how this concept might be used on a server, and the example you gave was basically moving UI state management logic to a server (but the results are still serialized and sent to a UI). Are there use cases for this idea that doesn't involve the UI at all?

Copied from the proposal (emphasis added):

  • It glides right in perfectly with tc39/proposal-eventual-send, providing a very nice and easy backend while letting those act as a front end. It might be worth adding a built-in wrapper for these as a follow-on if that takes off, or maybe even having async actor instances implement [[EventualSend]] and so on. One could also imagine using it as the basis of something similar to Cloudflare's durable objects.

This is in reference to, if it helps. Conceptually, it has a lot in common with Erlang's processes, just it's a more static form of it where Erlang's process dictionary is a very dynamic and free-form thing. You could also compare it to Akka's actors, where it shares a lot more in common. I focused on the UI side as it practically doesn't exist there, while in highly distributed and networked applications it's very popular.

1 Like