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.

Key takeaways While some reactive libraries are mature, developers still need time to fully understand the techniques

Reactive techniques requires a shift in thinking

Reactive techniques can be applied in a variety of ways

Reactive can improve predictability

The community needs to focus on educating beginners

Reactive techniques in programming are nothing new, but they’ve only just begun to garner more attention in JavaScript and web communities. Different libraries have emerged to give developers multiple ways to solve problems. Entire languages based on reactive techniques, such as Elm, have sprung up to provide even more options.

There’s been a lot of progress yet the technology’s adoption is still relatively new to those that work on the web.

InfoQ spoke with three panelists that use reactive techniques in different ways to get a feel for where reactive is at now and where it’s going.

The panelists:

Tylor Steinberger: Core contributor of Cycle.js

Brian Hicks: CTO of Asteris, organizer of elm-conf

Brian Cavalier: Creator of Most.js

InfoQ: Please introduce yourself and how Reactive fits into what you've been working on.

Tylor: I’m a core contributor to the Cycle.js project, a framework designed to help you write functional and reactive javascript. I’m also a core contributor to Most.js and XStream, which are both reactive libraries similar to Rx, but providing reactive streams with different project goals. Cycle.js is a framework designed entirely around reactive streams. Streams are used for everything from events, HTTP requests, state, and every other aspect of your application.

Brian H: I’m a regular user of Elm and just wrapped up organizing the first Elm conference, elm-conf. I also co-organize the St. Louis Elm meetup, manage the annual State of Elm survey, and write about it Elm at brianthicks.com. You might say I kind of like the language. Elm uses reactive patterns in the Elm Architecture (referred to as TEA). Essentially, you store state in one place and use message types to return new versions of little parts of that state. This is useful for one of my main focuses: building graphical UIs for DevOps tooling. Programming in this style fits in well with accepting structured logs from a backend. The data model matches by default without making me run around everywhere trying to sync state across different silos.

Brian C: I'm the creator of Most.js, a reactive programming library with an emphasis on extreme performance and simple APIs. Reactive and functional reactive programming have completely changed the way I think about designing software, and I try to apply the concepts in almost any application I work on. At my current job at Nowait, I'm focused primarily on our Node-based microservice architecture. We've been exploring ways that we can use (F)RP on the server side. Reactive has gotten a lot of attention in front-end JS apps. So far, though, there's been less work on how it can be applied server-side, and I think that could be quite exciting.

InfoQ: What's the current state of Reactive JavaScript in 2016?

Tylor: Reactive libraries in 2016 are very mature, robust, and flexible. If you have large applications with unique requirements a library like Rx can help you with the dataflow of your application in numerous ways. Other similar libraries like XStream provide similar functionality with a much smaller footprint if your application size is important. A library like Most.js is very useful for a programmer with functional programming background, as it has fantasy-land support, and the only functional API of popular reactive stream libraries. Most.js is also useful if your applications are very performance oriented.



With drafts of the ECMAScript Observable being written, all of the aforementioned libraries have created facilities for basic interoperation loosely based on those drafts. However, I’ve become rather pessimistic about the direction the ES Observable is going with things like cancellation tokens, and I foresee myself, and many others continuing to use third-party libraries for these needs.

Brian C: I’d characterize the current overall state as “young”. That might sound strange when we have mature implementations like RxJS and Most.js being used in production applications, and in other frameworks like Cycle.js and Angular 2, so I’ll try to explain. Exciting things have happened over the past two years: Reactive programming has come to the forefront in front-end JS on several fronts, and has become mainstream in terms of technique and mindshare. However, the current generation of implementations have some issues that we need to solve. For example: hot vs. cold can add significant cognitive overhead for developers, glitches and weird gotchas such as diamond shapes like: combine(f, stream1, stream1), while infrequently encountered, will be surprising to many devs. The community is just starting to research other implementation techniques, including rigorous FRP approaches to correctness, such as signal functions, signal vectors, pull-based, and push-pull-based. These can help us create implementations that rule out glitches. I think we need to invest more energy into researching them and how they fit into the reactive JS world. I think we’ve also just begun to scratch the surface on server-side reactive. Other communities (for example: Java, with work by Spring Framework, Netflix, Apache, etc.) have gone in big on reactive and data flow programming on the server. I can see reactive approaches being a big win for node-based server apps, especially when we start thinking about connecting them up to reactive front ends--reactive bottom to top.

InfoQ: When should developers use reactive techniques?

Tylor: I generally like to stay pragmatic about many things, but I feel that reactive techniques can and should be applied everywhere. When writing your applications, you’re able to write pieces of your application that are fractal and manage their own behavior. As opposed to passive (opposite of reactive here) programming which promotes programming via methods like Foo.setBar(x) where the dependency between Foo and the outside world is defined elsewhere from Foo. When programming reactively, Foo will listen to the outside world and decide for itself when it will update bar. A fantastic talk about this can be found here and does a much better job at explaining why reactivity is important.

Brian H: I think graphical UIs are the easiest application of reactive programming to understand. UIs need to have similar affordances to real life or they don't make any sense. When your user clicks something, you really should respond. But at the same time, events are coming in from the server. You need to respond to those, too! The unification of event streams makes reactive programming attractive for these applications. That said, every system has stimuli that need response. Reactive techniques are generally useful, even if the system at hand isn’t completely written in that style.

Brian C: I think there are at least a couple large categories of functionality where reactive techniques should be high on a developer’s list of choices: Asynchronous data flow, and values that change over time in response to events. In both cases, being able to manage and coordinate many things that are happening over time is key, and that is a strength of reactive techniques. A UI needs to react to user input events, while also handling sending and receiving data and events to and from a server. The user inputs may drive the need to send or receive data, and the data may drive changes in the interface, which may, in turn, elicit new input events as the user makes decisions about what to do next. Reactive techniques give the developer a set of tools, and even a DSL for modeling all of that in a sane way with expressive code. It’s interesting to consider the same situation from the server’s perspective. The server may be receiving requests for data, or data updates via HTTP or websocket, and in turn needs to access databases and other services. The server may be exchanging events via a message queue with other services. Here again, data flow, and the need to maintain an updated view of “the current state” in response to timely events are central, and reactive techniques make it much simpler to model and easier to get right. I think it’s worth noting that, beyond coding style, libraries, DSLs, etc., “reactive” represents a way of thinking about problems and solutions. As such, it isn’t free. Being able to “do reactive programming” or apply reactive techniques requires a shift in thinking and in how you design software systems. That takes time, and everyone is different., For me, that time has been very well worth it.

InfoQ: How can they benefit?

Brian H: Let's go back to UIs and The Elm Architecture. Your update function transforms your tree of state, which your view functions then render. Every message passes through this process, so you get predictable updates. The biggest benefit of reactive programming is the stable and accurate mental model this gives you. Pure functional programming allows us to go even deeper with this! Since we're confident that our functions return the same output for the same input, we can replay messages. This means we can create workflows around this predictability. Evan Czaplicki, the creator of Elm, demonstrated this at elm-conf with a new concept debugger. Using this tool, a QA person and a developer could collaborate on fixing an issue by sharing a list of messages. Then you could use a similar list of messages for making sure the bug doesn't come back. Reactive programming is what makes that possible!

Brian C: Thinking about and modeling change over time is hard. Writing code that manages it correctly is hard. Testing that code is hard! One big benefit for me has been the ability to model change over time in a simpler and more accurate way. As I’ve gotten deeper into reactive programming, especially when paired with functional programming, and pushing I/O to the edges of an application, I’ve found that writing good tests has gotten a lot easier. Reactive techniques allow modeling the pure computations (even computations that model change over time), to be tested without necessarily hooking them up to real I/O. For example, that makes it possible to test code, which when running within a real application would accumulate data coming from a websocket and update a UI, by hooking it up to a fake reactive event stream that simulates the websocket data in a compressed timeline (so your tests run quickly). In a recent small UI project I worked on, the client has 99% unit test coverage, and those unit tests all run on Node in about 1 second. The only code that isn’t covered is bootstrap code that accesses the document and window objects directly to setup some initial UI event streams. Similarly, it can allow incremental UI development without a server by, e.g., using a simulated event stream instead of a real websocket. It’s not hard to imagine having record/playback test event streams for such scenarios.

InfoQ: What do you think the future holds for reactive techniques in the JavaScript and web worlds?

Brian C: I touched on a few of my thoughts above. I think we’ll see more rigorous reactive implementations which deal with some of the tricky situations that the current generation of implementations have revealed. I think we’ll likely see more specialized implementations, perhaps some that are even more specialized for UI applications, and some that are more specialized for server applications such as big/fast data, microservice architectures, etc. I think we’ll continue to see a UI focus, but I also hope we’ll see some exciting things happen in reactive techniques for the JS server side. It will be interesting to see how the ES Observable proposal fits into this landscape, given that it seems to have the goal of being a language-level general-purpose reactive primitive. Perhaps it will end up being a good solution for many simple situations, and developers will look to more specialized third-party implementations when the situations require it (performance, high-speed/high-volume I/O, etc.). In general, all of that will make reactive techniques and reactive thinking even more of a staple for the JS community.

Brian H: The pattern is going to continue to find greater use, but only with proper education. An experienced developer can use reactive techniques even without the explicit support of a framework or language. That's fine for them! We want to be able to use new ideas in our systems. But at the same time, we’ve got to focus on educating beginners about this stuff. If we want reactive techniques to be standard we need to be receptive to their concerns. Making things easier for beginners to use usually makes them easier for everyone, in my mind. A fresh set of eyes will reveal problems that the experienced user glosses over. A friendly community and a good initial experience will go further than any technical merit will.

About the Panelists

Tylor Steinberger is a self-taught developer and a core contributor to Most.js, XStream, and Cycle.js.

Brian Hicks is the CTO of Asteris, a devops consultancy based in St. Louis, MO. He organizes elm-conf US, blogs about Elm (and other things) at brianthicks.com and runs the St. Louis Tech Slack. He enjoys biking around St. Louis, hanging out with his wife, and tweeting about his cat.

Brian Cavalier is the creator of Most.js and an architect at NoWait.

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.