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)

4 Likes

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.

2 Likes

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:

Is it fair to say all are moving towards rocket.jl ?

No, I don’t think one can say that:

Package used by
Observables 33
Reactive 5
Signals 0
Rocket 0

So Both Signals.jl & Rocket.jl, aren’t actually used by any Package, based on JuliaHub, so I don’t think one can say “all are moving to rocket.jl”.
Reactive is deprecated in favor of Observables.jl. I’m not sure why Rocket.jl doesn’t compare against Observables.jl in it’s benchmark, considering it’s the most widely used Package, while the others are kinda deprecated/unused.

I added Observables to the mix:


To be fair, I’m pretty surprised Rocket faster than Observables. Would be nice to investigate that, since it either must be a performance bug or a trade-off.

Don’t get me wrong, Rocket.jl looks really impressive - but also really intimidating. The API is quite complex, and the implementation seems to be huge. Observables core on the other hands is implemented ~350 lines of code, which helps a lot with the maintenance and finding bugs, so I guess I at least won’t move to Rocket.jl anytime soon…

5 Likes

Hi!

Thanks for the interest in our package. I’m the main developer of the Rocket.jl. Regarding your question why its not compared with Observables.jl. In my opinion it is hard to compare this packages, because Observables.jl is an implementation of Observable pattern (simple and only in 350 loc), while Rocket.jl is a full and huge reactive framework and provides more functionality (mostly inspired by RxJS package).

Observables.jl is a good package, but it does not provide any operator (except map, correct me if Im wrong) to work with observable streams of data. On the other hand Rocket.jl provides 52 built-in operators, such that reduce, scan, share, map, filter, merge, concat, switch_map, concat_map and many many others ([documentation](https://biaslab.github.io/Rocket.jl/stable/operators/all/)). Rocket.jl also provides 21 creation operators to build observables from scratch or using other observables and it allows creation of observables with no initial state at all. Rocket.jl also exports nice and convenient operators piping syntax for functional reactive programming. It mostly depends on your needs, if you are fine with Observables.jl package than you probably don’t need Rocket.jl.

However, regarding benchmarking, I understand you confusion, I will add Observables.jl to the benchmark list, at least for the map operator. (You are also welcome to make PR, we will be happy about that). I did simple benchmarking on my side and Rocket.jl is faster in sync mode. We worked hard to make Rocket.jl observables implementation + operator transformation zero cost abstraction (where possible, e.g. over regular arrays like in benchmarking scripts).

The API is mostly inspired by the RxJS package and copies it in may ways. Implementation is quite complex and huge, true, but is is also very well tested and covered.

Rocket.jl is a very young package, we use it for our research purposes and will be happy if someone else will use it.

5 Likes