Considering switch Observables.jl to Rocket.jl?

[XLin0mu]

Observables.jl works a bit of slow for high frequence tasks, while Rocket.jl works better than Observables.jl on both time and memory cost(and other reactive packages).

Also, Rocket.jl have more up-to-date maintenance, while Observables.jl has been almost a year without an update and has not yet released its 1.0 version.

On the other hand, the documentation and API of Rocket.jl are also more comprehensive than those of Observables.jl.

Reposity of Rocket.jl:
https://github.com/ReactiveBayes/Rocket.jl

[SimonDanisch]

I think combining Rocket and Makie could be interesting, but I dont see it replacing observables in the foreseeable future.
We actually plan right now to remove Observables from Makie's internals and use a very lightweight, plot specific way to pass events from the user to the backend: #4360. This will make it less important what "observable" framework you use to update Makie plots.

There are several reasons why I won't consider Rocket right now for Makie's internals:

• Every time I look at the docs, I come back confused. This is likely because I'm not used to the actor principle and haven't given it enough time to learn it. So not a strong reason, but certainly doesn't help.
• Correct me if I'm wrong, but that Rocket is more performant must be a trade off. The main performance culprit for Observables is, that we had to use invoke_latest, since we had several serious bugs without it because user callbacks would call into the wrong world age. If Rocket doesn't use invoke_latest, it's either more complicated to define safe callbacks for it, or it will need a lot more compile time. ~20-30% of compile time comes from Observables already, so a framework being even harder on the compiler is currently hard to justify. If it's a secret third option, I'd be happy to learn from it.
• It took several weeks to go from React.jl to Observables.jl, which wasn't a fun refactor and someone needs to pay for it/put the work in. Rocket.jl is much more different from Observables.jl than React.jl from Observables.jl, so I expect it to be an even harder refactor, which will need a much better justification in favor of Rocket.jl than "it may be faster in a few specific tasks".

However, what we could start with is looking at writing tutorials and maybe add lightweight APIs for how to best use Makie & Rocket together. E.g. a simple way to hook up a rocket signal to update plot attributes.
I'm happy to answer questions about it, but don't have time to write such tutorials/integrations.

[XLin0mu]

Glad to hear your plan of self-building interface of Observable pattern. Considering on the positioning of Makie.jl, I believe that it would be better than any specific implementation package at most of scene.

The reason I suggest Rocket.jl is mainly because of how Observables.jl work like, while the factor of Rocket.jl is just a promotion. (and I have to agree that Rocket's documentation is kind of confusing)

Rocket.jl may could be a better choice even with compile time tradeoff, since it attempt to work like RxJS, which design for pretty complicated async tasks. However, the greatest tradeoff of Rocket.jl and RxJS may be the steep learning curve for them.

At least Observables.jl is easy to use, which actually enough for lots of situation. So it would be better to put the choice decision to users for different applyment situation, while that's another reason I agreed for your dicision about self-building interface.