RxFiddle has multiple goals:
The common goal here is to help developers. Whether you are building something yourself, viewing some code of a collegue or learning Rx. Make doing Reactive Programming easier than ever. I wanted to do something back after Rx gave me such a powerfull development tool.
Rx is available in many flavors. I investigated whether it is possible to instrument RxJava and RxJs and found out both the JVM and JavaScript libraries are perfectly instrumentable. Considering the visualization tool is browser based the development cycle could be sped up by using a in-browser instrumented version of Rx.
Using RxJS 4.1 is mainly an effect of what I had available when I started of with extending RxMarbles. Creating instumentation for RxJS 5 should be possible too but I expect some more work because of the new ecmascript module structure of version 5.
Update [2017-05-02]: version 5 is (mostly) supported in the version that is available at rxfiddle.net. Be aware that version 5 brings Ecmascript modules into the mix, which makes it harder to swap prototypes (module exports are immutable). Furthermore version 5 has some performance features which we need to revert in order to create a full model of the program (affecting ScalarObservables). This should not affect your program in any other way than it's performance, but for non-high-througput samples you should be fine.
Actually, it is. During the last year I found out just how complicated instrumentation, call stacks and visualization are. Instrumenting Javascript is relatively easy - you just swap the prototype - but you do need a lot of bookkeeping to relate all the gathered information to Observables, Observers and the events flowing through. If you have got the basic map and filter operators working you are still far from done: throw Subjects into the mix and your whole world turns upside down. Same for higher order streams and merging them.
And you can't just be lazy and correct stuff once you have more information. We are talking Rx here so I wanted everything to be streamed, push based. Any intermediate debug state should be a valid state itself.
I first used Rx.NET in 2013 while doing the last project as an undergraduate student. I remember that it took me quite some time to fully understand the concepts of reactive programming. I did not really see how the data would flow through the stream unless I sprinkled println statements through the stream. When I first used the debugger to step through that code I thought about how awesome it would be to have better tooling. Fast forward to 2015 and I'm laying out the plan for the rest of my master, and there is Erik Meijer - inventor of Rx - as a professor at my university (TU Delft, The Netherlands).
The goal of the survey is to measure the difference between developing reactive programs using traditional methodology and the development flow where the developer has the option to use RxFidle's capabilities. I hope to speed-up and improve the comprehension of reactive code. The hypothesis is that using RxFiddle the developer gains a better understanding of the reactive code and does so quicker.
Yes! I got a lot of external inspiration. Andre Stalz has done some amazing work creating RxMarbles. I've spend some time trying to evaluate whether I could just work with that and extend it, however RxMarbles is mostly built around pre-specified examples, usable in for example the ReactiveX documentation, while RxFiddle aims to visualize áll your reactive code and operators. No matter how crazy you get.
RxVision is doing something comparable to what RxFiddle is doing. It instruments the Rx prototype and plots a visualization. I found it to be limited however. The implementation lacks support for many very common operators and its visualization is very unclear to people who have never seen the tool. It does not really relate to marble diagrams like I feel RxFiddle does.