BT

Your opinion matters! Please fill in the InfoQ Survey!

Q&A with Paul Daniels and Luis Atencio on RxJS in Action

| Posted by David Iffland Follow 3 Followers on May 11, 2017. Estimated reading time: 10 minutes |

Key Takeaways

  • What challenges face developers learning reactive programming?
  • Where does RxJS fit in the JavaScript landscape?
  • Is reactive useful everywhere?
  • What's the future for RxJS?
  • Use RxMarbles to visualize reactive streams.

Reactive programming techniques are becoming more prevalent in the constantly changing JavaScript landscape. This article series hopes to provide a snapshot of where we're at, sharing multiple techniques; variations on a theme. From new languages like Elm to the way Angular 2 has adopted RxJS, there's something for every developer, no matter what they're working with.

This InfoQ article is part of the series "Reactive JavaScript". You can subscribe to receive notifications via RSS.

 

In their forthcoming book, RxJS in Action, authors Paul Daniels and Luis Atencio give a terrific introduction to what is likely to be one of the most dramatic changes in the way JavaScript programmers write code in the next five years. Among Reactive JavaScript libraries, RxJS is one of the most popular and their book is an essential guide.

The book is broken down into three parts. Naturally, the first part aims to bring the reader to a better understanding of reactive programming, functional programming, and observables. For developers coming from an imperative background, learning to think reactively may take some getting used to. In a literal sense, time is of the essence; the focus on time as a fundamental component of reactive programming is introduced and reinforced throughout the book.

This section includes good examples of how RxJS can dramatically reduce the amount of code the developer has to write. In Chapter 4, for example, the discussion on the debounce includes not only the RxJS functionality, but the full implementations of how to do it without RxJS. The authors take the time to spell out exactly what would have to be written in order to write an equivalent feature without using RxJS and where those implementations stumble. Even if the reader isn't able to immediately start using the fullness of RxJS and it's plethora of combinable operators, the simple examples offer a baseline of functionality that can be incorporated with ease.

In the second part, the authors dig into some more realistic examples of how to use RxJS. The concepts get a little more complicated here. Multiple streams are merged and combined in different ways. One of the most useful sections is that on automatically retrying failed sequences. With a single line of code, developers can automatically retry an operation.

The third part focuses on more advanced techniques. The authors spend time on the difference between hot and cold streams and how to switch between them. Testing gets an entire chapter, showcasing how streams testing differs from object-oriented testing. Near the end of the book, the authors show how RxJS can work with React.js and Redux.

Throughout the book, as with other reactive trainers, marble diagrams are used to help the reader visualize what is happening. This is helpful, but due to the limitations inherent in the size of the book page, some diagrams don't provide enough clarity about what's going on. InfoQ recommends the above link, which lets the user move events around, as a supplement to gain a thorough understanding of how the pieces fit together.

InfoQ sat down with Daniels and Atencio to discuss their book and RxJS in general.

InfoQ: What's the most challenging aspect of RxJS for developers coming from an OOP or imperative background?

Paul Daniels: For me, coming from a background with very little functional programming, the most difficult part about RxJS was understanding the concept of data in motion, and I see this a lot in GitHub comments and on StackOverflow as well. Coming from an imperative code background it is hard to reason about why I can’t just reach out and grab some data in a pipeline. It takes a while for many developers to get past thinking of Observables as Arrays with events or EventEmitters++.

Luis Atencio: For us, one of the key principles that we emphasize in the book is that proper RxJS implementations should use functional programming. The two kind of go hand-in-hand. So, in order to jump into RxJS, developers must first jump from OOP or imperative into functional and this leap is sometimes a little intimidating. On the other hand, RxJS simplifies the nature of asynchronous programming which is usually a barrier to entry for JavaScript developers and RxJS makes unifies that model of development.

InfoQ: How broadly can one apply the reactive techniques? Is it a tool that developers will reach for more and more as they become more familiar?

Luis Atencio: Absolutely, I'm currently working on a project that orchestrates multiple services and APIs together. I found that threading async calls through observables was the best solution, and it's been extremely elegant. To this day, I'm still uncovering more and more techniques and operators to implement, so I always feel that I've only scratched the surface of what's possible.

Paul Daniels: In many cases, I start from a Reactive-first mindset, that is, I approach problems as “Why would I not do this with reactive?” That is usually driven by the simple reality that almost every application we make is going to have user interactions, web requests or some other asynchronous action. Using a library like RxJS means that there is no additional boilerplate, it’s clean and it just works, and that is the kind of reliability that developers really like.

InfoQ: Are there times when reactive is not helpful? For example, in Chapter 2, you use banking software as an example of how OOP is done. How would banking software be implemented reactively?

Luis Atencio: RxJS is ideal for software that needs to handle inputs that come in from multiple angles such as lots of user input, API calls, websockets, etc., all coming in at once and factoring into your business logic. When faced with such a heterogeneous data set, RxJS is powerful in that it can easily consume and consolidate these event streams under a single programming model. If you don't have such a need. In other words, if the level of user interaction is minimal, or your data is driven from a few database calls, then RxJS may be overkill.

Paul Daniels: I don’t think I have ever come across any scenarios where it is not helpful. We often draw parallels in the book to the similarities between the RxJS interface and that of the built-in Array. In fact part of the unifying data model of RxJS means that Arrays are also a type of data source, so at the very least we could consider RxJS a more efficient alternative to operator chaining on Arrays since Observables produce less overhead. However, as Luis points out, pulling in RxJS just to do synchronous data manipulation is likely a heavyweight solution to a lightweight problem.

Building banking software is no different than any other application. With Observables like functional programming you want to think about what the input to your program is and what the output is. From a very high-level when we consider a banking example, there are a couple flows that stick out, like checking balances, making payments or transferring money. Once you have that as a starting point, you can start picking apart smaller and smaller pieces to model and then through the power of functional programming you can compose those sub-streams together into a working app.

InfoQ: How does RxJS differ from other reactive libraries? What led to the acceptance of RxJS as the major player?

Luis Atencio: The RxJS observables are also being implemented as a TC39 Spec. I think this sets it apart from others such as Bacon.js. Together with an incredibly large community behind all Reactive Extensions. In my opinion, this is the only player in reactive streams.

Paul Daniels: A large part of RxJS’s original success I think can be attributed to its recognition as a port of the popular Rx.Net library. When it originally burst on the scene in 2012, it was one of the only reactive JS libraries, so for a lot of the early adopters that made RxJS the default implementation of Observables (which means most of the gurus in the field got their first taste of Observables in JavaScript through RxJS). Since then, there have been lots of exciting developments in the space. RxJS, despite its overall focus on speed in the RxJS 5 revamp, has been unseated as top dog for raw performance by some of the perhaps less known libraries like most.js and xstreams. However, I think as Luis astutely points out, RxJS has moved into the role of standard bearer by being essentially the template for TC39 observables and representing both stability and versatility of a battle tested system which makes it a good candidate for others to build their platforms on top of.

InfoQ: How does RxJS 5 differ from prior versions?

Luis Atencio: RxJS 5 follows the TC39 Observable specification, so this is crucial for interop with not just core JS down the road, but other libraries that are looking to wrap or extend Observables. Another key focus was on speed as well as a significant reduction/simplification of the API surface. This last point for me is one of the key benefits of 5. Looking the set of operators in RxJS 4 is very intimidating, so I'm glad they focused on keeping what's important.

Paul Daniels: I think Luis said it very well. Interop is a very exciting area for me because it was something that I always admired about the Promise ecosystem. The ability to readily map one Observable implementation onto another really opens the environment and makes it so that all players are welcome. Here again we see the unifying model of RxJS but on a library level. Additionally, the library is making strides toward more modularity, the goal being to eventually be able to import only the operators that you need and thus minimize your bundle sizes. All too often when you look at a lot of sites out there, they pull in 1MB of vendor packages and a 50Kb application code.

InfoQ: How you would rate the uptake/acceptance of reactive and RxJS in particular among JavaScript developers?

Luis Atencio: I think Observable are here to stay. They are proof that functional programming offers a compelling way of approaching software problems. I've seen Rx, in general, being heavily used in API design. RxJS, in particular, is also embedded into Angular. The large community around RxJS has also been quite impressive. Lot's of people building extensions and plugins that interface observables with other frameworks, like Redux.

Paul Daniels: I think the fact that RxJS is now shipped as part of Angular and is the driver in a hugely popular Redux middleware says it all really. Rx is in a lot of places people probably wouldn’t have imagined a couple years ago and that is opening even more doors. And the TC39 specification only solidifies that role as a key player going forward.

About the authors 

Paul P. Daniels is a professional Software Engineer with a B.S.E in Computer Science and over 5 years of experience in software engineering, developing applications in .Net, Java, and JavaScript. A regular user of RxJS, he is active as a member and a contributor in the RxJS community. 

 

Luis Atencio is a Staff Software Engineer for Citrix Systems. He has a B.S. and an M.S. in Computer Science and works full-time developing and architecting web applications using Java, PHP, and JavaScript platforms. Luis is also the author of Functional Programming in JavaScript.

 

Reactive programming techniques are becoming more prevalent in the constantly changing JavaScript landscape. This article series hopes to provide a snapshot of where we're at, sharing multiple techniques; variations on a theme. From new languages like Elm to the way Angular 2 has adopted RxJS, there's something for every developer, no matter what they're working with.

This InfoQ article is part of the series "Reactive JavaScript". You can subscribe to receive notifications via RSS.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT