2017 is a revolutionary year in JavaScript land for many reasons. With last year’s final release of Angular 2, the announcement of React Fiber, the final release of RxJS and the massive adoption of Vue.js amongst JavaScript fanatics, the industry’s run towards a better modern web is quickly increasing in pace.
Trends come and go, as do frameworks, but there is one trend that looks like it’s here to stay. That trend is reactive programming.
Reactive programming is not new. Libraries like RxJS have been around since 2009, but for the most part, use has been confined to a small group of reactive and functional programmers and academics. Until recently, developers had no way of understanding what it was due to poor documentation and lack of widespread knowledge. The concept did not become broadly accepted until the adoption by front end frameworks in the past few years.
Because of framework adoption, reactive programming, Observables, and RxJS are all buzzwords we’ve heard around the internet. It has quickly become the “cool thing to do” these days. But, there is a reason industry influencers are adopting reactive programming, and it’s not because it’s “the thing to do”. There are strong technical and business reasons to adopt and invest in reactive programming.
Reactive Programming — The Big Picture
Imagine if you could have anything in computer science talk to anything. With reactive programming, you can. Did you know anything in computer science can be an Observable? This means we have, at our fingertips, a common higher order language that unites everything that exists in computer science.
Practical Use Cases for Rx
The dream of uniting all of computer science may seem be a bit of a hyperbole, but it’s not far from the truth. Being able to represent the setup and teardown of anything, any number of values over any amount of time, animations, messages arriving over a network, the entire lifecycle of a view, combined with the fact that you can observe anything over time, makes them very powerful. More importantly, because all Observables have the same shape and can represent almost anything, it becomes trivial to compose things together and have them talk to and notify one another.
Reactive programming is a more efficient way to code and has been adopted by industry leaders as the new standard for developing applications with clean code. It’s a real, tangible method with great tools to allow for better development standards within organizations.
A Language That Spans All Frameworks
We can finally surpass just adding numbers with reactive programming. It is a declarative language on top of JavaScript that encompasses higher order functionality, meaning you can say “do these things”, and do that in one line of code. Being able to talk on top of a language that spans across all frameworks is powerful. It does for events what HTML does for layouts. Think about how easy it is to add a div. In Rx, you can simply add an operator and the behavior changes without touching a single line of code.
Quick, Swift Adoption in JavaScript
Two large reasons it is evident that now is the time to adopt reactive programming are the TC39 Observables proposal and the confirmation of frameworks like Angular (2.x)’s adopting reactive programming through libraries like RxJS. Below is an illustration of npm downloads per day in 2016 for RxJS.
With Observables on their way to becoming native to the browser, soon, the Observable type will be used to model push-based data sources such as DOM events, timer intervals, and sockets. You can follow the spec and find more details about specific use cases and implementations on github.
Though modern web frameworks have adopted reactive programming in various, non-complete forms, Angular (2) is the only framework that has embraced reactive programming in its true form, using Rx for their async primitive.
Observables supporting cancellation (unlike promises) is one of the key reasons for single page application adoption of Rx. The shape of Observables also allows you to support any type of async including Ajax animations, websockets and user events.
Delivering Complex Features Faster
Libraries like RxJS help enable developers to deliver complex features quicker with less, more maintainable code. Because it’s declarative, it enables you to more rapidly add features and pivot. If you want to add a feature you can add it in a couple of lines of code and write them in a framework agnostic, domain specific language.
Development teams who knows Rx have the tools they need to implement complex features in applications in a few trivial lines of code, such as multiplex web sockets, drag and drop, autocomplete, text box, client side rate limiting, and step by step wizard patterns.
One Interface to Rule All APIs
With web development being driven by events from various APIs, code for interfacing these APIs can become long and convoluted. But, by wrapping your code in an Observable using RxJS, you are able to create one interface that all the APIs can understand, enable faster web development, easier composition, and drastically decrease the amount of time adapting one type of data to what another API expects.
Using Rx Today
Though Rx may seem awesome, it’s easy to create excuses as to why it’s not the right time to adopt reactive programming, such as the extensive work a code refactor may take. The great thing about Rx is, you can start benefiting from refactoring towards Rx with little work. Most implementation of Rx is writing a few lines of code to interface with existing code.
Reactive Programming Types
Most reactive programming is push based. Push based Rx is certainly more ideal for front end web development because most interactions are events pushing at you such as DOM events and mouse clicks. Certain frameworks, however, such as Ember, however, have adopted pull based reactive programming.
With pull based Rx, we tell system to give us a value and it pulls values down when requested. Pull based reactive programming is great in situations where controlling back pressure is necessary and for busy systems where you may want to control when you get information. You will get pushed a notification that a value has changed, but you don’t get told what the value is until it’s been requested.
Contrasting against push based Rx, which pushes values through a series of steps and gives you answers at every interval. Push based Rx pumps values out as fast as possible, which makes it more performant per value, but the tradeoff is not being able to control when you get the value.
Investing in Reactive Programming
Reactive programming has enabled web developers to produce features faster by providing them with the ability to compose complex tasks with ease. The more people understand reactive programming, the more productive we as one modern web will all be. The only barrier to adoption is not understanding the paradigm and the language around it.
Reactive programming is already enabling our lives to be better by powering products built by Netflix, Slack, Microsoft, Facebook, and many more.
This article was co-written by *Tracy Lee and Ben Lesh, co-founders of This Dot Media and This Dot Labs. To learn RxJS, request an RxWorkshop.*
Need JavaScript consulting, mentoring, or training help? Check out our list of services at This Dot Labs.
Top comments (1)
Phew... how to start here... my question is: „more efficient“ compared to what? If you’re talking about JavaScript callbacks, ok then maybe you’re right. If you compare it to imperative sequential code, then I have to object.
I’ve written larger applications in both Typescript with RxJS as well as server-side Java applications with Spring WebFlux. And oh boy, the simplest tasks gets so hard to write compared to doing it sequentially. But not only that it’s more complex to get things done, the code is cluttered with framework boilerplate like Observable<>, flatMap, filter, etc. I want to have my code to be as much human readable and as much domain specific as possible. Reactive code isn’t and it’s really hard to refactor as well.
So to sum it up, reactive code is IMHO only one step to code that looks synchronous but works asynchronouly under the hood. This is achieved using coroutines.
It’s a awhile ago but I’ve Witten an article about it if you’re interested:
Don't Drink Too Much Reactive Cool Aid
Jan Wedel ・ Jun 23 '18 ・ 7 min read
So I really hope and believe that this is not the case.