State of Signals


There are a lot of packages for signals these days:

Reactive seems widely used, but has some failings (lack of push/pull etc). Apparently Observables.jl solves some of these, and Signals.jl solves others. I’m not sure what ReactiveBasics is for.

Where is this headed? What should we use and support in future? It seems that having too many of these standards may cause pain with package compatibility and duplication of effort.

As an example, after recent updates I have found that Interact.jl is not really working currently anymore for IJulia. InteractNext seems like a good alternative, but uses Observables.jl. Switching to InteractNext means rewriting code to use observables and losing compatibility with other packages that use Reactive.jl signals.

(I’ve just written a small package for automatically building signals recursively from any type then using them to construct plots with toggle/slider controls for an instant interface. It works great, except the actual widgets are broken for my main use case - jupyter. So I’m wondering where to go from here)


Yeah. Julia feels like python from years ago. I heard python used to have 15 web frameworks.

Just to try them all. And then let people which one is best.


See also this thread:


ReactiveBasics was written to have the same API as Reactive but operate synchronously. The main reason for that is synchronous operations are faster. For my uses, Observables should work well, but I haven’t really tried it, yet.


Thanks for the replies, I guess I’m really wondering since those earlier threads wether there is any consensus emerging on the direction things are going - before I commit to building a bunch of modules that support one or the other standard, or put a lot of time into fixing issues with modules firmly using one standard.

I also feel like the Julia community is a lot more organised than python was! People don’t seem to just let things get totally fragmented until a winner emerges, but plan a little more around what seems like the best framework going forward.

It’s good to hear that reactive basics is not actually a different api :slight_smile: