Reactive programming is a powerful, and sometimes misunderstood, programming paradigm. Few people have more to say on the topic than André Staltz, who will be speaking at upcoming Reactive Conference. I asked Andre to clarify some of the concepts and offer advice on when it might be a good idea to choose the reactive approach. If you are interested in these concepts, I hope you find his answers as helpful as I did.
Interview with André Staltz
How did you get into reactive programming?
Before joining Futurice, I had never heard of reactive programming. It was through work colleagues who were using Bacon.js, RxJS, RxJava, ReactiveCocoa, that I got curious about reactive programming and functional reactive programming. Soon enough, I was using RxJava extensively in an Android project, and had to learn Observables and operators the tough way: by using it for real to deliver software with deadlines. My learning process was guided by believing that "there must be the 'reactive' way to do this" and by sketching out dozens of marble diagrams on paper notes.
What are the common mental barriers developers have to overcome when learning and adopting reactive programming?
Most programmers exposed to reactive programming, me included, were used to "triggering", "updating", "dispatching", "firing" methods and procedures. Those are idioms and techniques opposite to reactive programming, where instead we try to declare what is "triggered by" or "updated by". The biggest challenge is simply to go through the mental revolution from "A changes B" to "B is changed by A". After that, the smaller challenges are learning Rx operators, where they apply, and common techniques.
Do you find people are confused by the difference between the naming of React, the Facebook library, and reactive programming?
Unfortunately, yes. reactive programming is ancient, even though it has become a modern approach through Rx and Akka and others. React, on the other hand, uses a few reactive techniques, and therefore borrowed the name. I like to compare these two to "car" and "carpet". There is a carpet inside your car, but cars and carpets are entirely different objects. There is some reactive programming in React, but these two are entirely different things. In fact, there is even some reactive programming in plain old callbacks, so I wouldn't consider reactive programming a noteworthy property in React.
Do you see instances where people choose React/Redux, when they would be much better served with purely reactive approach?
Yes, I do see those instances. However, I don't think that is always the case. There are even cases where people choose React/Redux (or any unidirectional data flow approach), when they would be better served with two-way data-binding, like in Vue.js. Each approach has its ideal use case. When it comes to the fully reactive approach, I think it works best for applications that need to handle incoming data from multiple different sources: WebSockets, Firebase, Sensor data, Keyboard, Kinect, to name a few. React/Redux works decently when you have only graphical UI in the browser, a few user events from clicks, and a single server to communicate with.
Are there problems that people could use reactive programming for that are typically overlooked?
There are many cases where reactive programming helps. RxJS and similar libaries are by far the best tool today to handle cancellation of all sorts, in the easiest possible way. Promises are not cancellable. This means you cannot stop an in-flight request built with fetch(). Even if you implement cancellation logic yourself with manual state bookkeeping and Ajax, the amount of code required is disappointing. It turns out that most frontend developers ignore cancellation because they believe hardware resources are plenty. However, with RxJS, cancellation is easy, idiomatic, and semi-automatic, so that you sprinkle a few operators and your code then handles complex asynchronous cancellation. RxJS is not just for cancellation, though.
What will you be talking about at Reactive Conf?
I will be talking about how we can go beyond console.log and the step-through debugger, and how we can develop new code visualization tools that help us understand and debug our applications. In particular, I'll guide people through the Cycle.js DevTool, a tool that visualizes the whole code in your application as a dataflow graph, and how you can observe the events flowing in real-time as you use the application.
What is Cycle.js and why did you create it?
Cycle.js is a JavaScript framework for building user interfaces. It allows you to build typical frontend applications like your favorite e-commerce single-page app, but also has a flexible architecture that knows how to accommodate different use cases like the use of game controllers, WebSockets, keyboard, Kinect, in a structured way with good separation of concerns. I created this primordially because I wanted to solve "User Interface Architecture". I wanted to have a guiding principle and essential tools to handle any kind of UI app I build. I believe JavaScript will power nearly all UIs in the future, and there has to be a common way of programming them with a focus on code readability and productivity.
What is important to the ongoing health and success of the Cycle.js project?
To be honest, money. Not for myself, but for the contributors. We have reached the scale where as one person I cannot handle all issues and requests alone, and it's crucial to have core contributors. Tylor Steinberger and Frederik Krautwald are two people I am immensely grateful for helping build the framework as volunteers. We run this as a true grassroots open source project, not as a project belonging to a large tech company like Google or Facebook. Recently, we have set up a donation site for our contributors.
Would you like to point to any resources (a favorite talk of yours, a good tutorial, etc) for anyone looking to get into reactive programming?
I have three links: one is a talk I gave, another is a good introductory blog post written by someone else, and another is an unrelated but highly inspiring talk about asynchronous logic programming:
Top comments (0)