# Rx and reactive programming for handling asynchronous app development

DevFeed: [Rx and reactive programming for handling asynchronous app development](<https://devfeed.tech/articles/rx-is-coming-25320.md>)

Original publisher: [Read original article](<https://kau.sh/blog/rx-is-coming/>)

Author: Kaushik Gopal

Published: 2015-03-02T07:00:00Z

Content type: opinion

Language: en

Sources: [Kaushik Gopal's Site](<https://devfeed.tech/sources/kaushik-gopal-s-site.md>)

Topics: [reactive](<https://devfeed.tech/topics/reactive.md>), [Library](<https://devfeed.tech/topics/library.md>), [Development](<https://devfeed.tech/topics/development.md>), [App](<https://devfeed.tech/topics/app.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [app](<https://devfeed.tech/tags/app.md>), [asynchronous](<https://devfeed.tech/tags/asynchronous.md>), [developers](<https://devfeed.tech/tags/developers.md>), [development](<https://devfeed.tech/tags/development.md>), [library](<https://devfeed.tech/tags/library.md>), [network](<https://devfeed.tech/tags/network.md>), [reactive-programming](<https://devfeed.tech/tags/reactive-programming.md>), [server](<https://devfeed.tech/tags/server.md>), [ux](<https://devfeed.tech/tags/ux.md>)

## AI overview

The article argues that Rx, or Reactive Extensions, can help app developers manage the complexity of asynchronous programming, including network requests, streaming data, failures, and updates across services and devices. It suggests that reactive programming may become increasingly important as more applications depend on online data and interconnected platforms.

## Source excerpt

i spent a huge part of my 2014 on "Rx" (or reactive extensions) which is essentially a library that helps with a development pattern called "reactive programming". i think Rx is going to be huge in the app development world. it's already picked up a lot of steam, but i think it's going to become a staple for professional app developers. consider this extremely common scenario: you're in Burundi surfing facebook. you want to get the latest updates from facebook, so your smart phone (from a network in Burundi) shoots a request to the facebook servers in Menlo Park. that server reconciles your request and sends back 5 epic selfies from your dearest friends. in our universe, this takes time. maybe not a whole lot according to you (a second perhaps) but for that mini super-computer you hold in your hand, that's 1000000 microseconds. that's a long time that you're asking it to twiddle its thumbs (given that it usually processes stuff in a couple of microseconds). what's it supposed to do until it hears back from the facebook servers? after it's done showing you the updates for your first screen, when would it know to trigger another update? what if the data that came back from the servers indicated that you need some more information? what if the third request in that chain failed for some reason? welcome to the world of asynchronous programming. Rx (or FRP as it is mistakingly assumed to be synonymous with) was built to deal with a lot of this pain. a natural question is: don't app developers do this anyway today? yes we do. but it's painful and error prone. it also results in bad UX (spinners, progress indicators, alert dialogs for failed network issues and other technical problems that users really shouldn't have to deal with). you can get by very far without having to deal with many of the aforementioned problems (like keeping all your information saved on your device instead of say a big server machine located elsewhere that would require a network connection) but as