Reactive programming emphasizes writing code that is readily responsive to events. Reactive programming is increasingly popular due to highly interactive websites like Netflix. It draws on the value of functional programming calls like Map, Reduce, and FlatMap. If you're a fan of functional programming, you will like this episode.
Today's guest is Matthew Poldwysocki. He works at Microsoft and he's a contributor to Reactivex.js. And he's also a speaker at the upcoming Fluent Conference. He joins us today to chat about Reactive Programming and the Observer Pattern, and his thoughts on where the future is going with Reactive Programming.
Matthew Poldwysocki is a principal engineer at Microsoft. He's giving a talk at the upcoming O'Reilly Fluent Conference called Building our Reactive Future. Matt, welcome to Software Engineering Daily. Oh, thank you.
Thanks for having me. I'm excited about it. Yeah, same here. So when programmers have a problem in JavaScript, they often try to solve it with callbacks and events.
What are the problems with this approach? Well, it's a number of things. For example, callbacks, which you end up having is somehow you have your state sitting around at the very top or intermingled in between, as it were. And then the overall flow becomes very hard to understand.
You're like, okay, now do I have to handle an error here? Where does the error go? Who catches it? Okay, now I'm going on to the next step.
The next step requires this much state. Okay, well, now I'm going to update the state here. I'm going to have to check for errors. Where do all the air checks go?
How can I recover? Any number of those kinds of things are kind of the drawbacks of callbacks. What a lot of people say is, you know, it greats the pyramid of doom or what I call the cows head, which is more along the lines of your code just starts to walk off the side of the screen because you're nesting all of your callbacks, you know, doing all your air check. And then at the end, you're doing all your air checking, as well as you're coming back.
So that's a definite problem. What I would call say, the composition problem is it's not a very linear kind of thing. It is that you have these very complex state machines that you're trying to execute. And there's no real good way of reasoning about it because all you're dealing with is being stuck in a continuation passing style where you're like, where does it go now?
Okay, now I just did an alternate path. How do I know? And so some recent talks that you've given have largely focused on reactive JavaScript applications. And in the browser, we can build games like Super Mario Brothers, or we can build Photoshop, in the browser, we can have video players, and all of these applications, if they are built responsibly, can be based upon the concept of the observable.
Could you define the term observable? Sure. So the idea of an observable is the fact that you have a producer of some sort of data, whether it's mouse movements, whether it's some Ajax data, whether it's keyboard events, any number of things, when you're talking about games. But even the game cycle itself is a producer of events, as it were.
So what I call observable is more along the lines of it's a producer of push notifications. And so it produces all of these sorts of things that you have an observer on the other side listening for. So you basically, it's the Hollywood principle, I don't call us, we'll call you, so you just basically hand me an observer. And whenever I'm ready to start producing values, then I will start sending them to you.
So that's what I would call an observable, is just the idea is that it is a producer of content that you have someone else listen to. How does the observable make asynchronous programming easier? Okay. Well, the way that we've designed the observable is actually fairly interesting in the fact that we, when we were designing this whole paradigm, we were looking at basically trying to make JavaScript programming easier.
And this was in the days before promises really existed, and a lot of these other things. So we kind of needed a way that we could easily produce, have first class objects, as it were, to encompass things like mouse movements to mouse clicks to any number of these kinds of things that we'd want to basically do. The problem was, is that in standard JavaScript, that doesn't exist with standard events. Yes, it acts like a subject observer pattern, but all you're doing is dealing with callbacks at a certain point.
I just say, add an event listener, give it a callback and remove event listener. And I remove that callback. The problem is that you can't really take those, and turn them into a Lego box or building box upon one another, because you're like, okay, I'm going to nest this event handler inside of this event handler. So it's basically, you're going back to the callback problem that you had, which is the coordination of all of those things.
So what we decided to do was try to create a first class object, which encompassed all of those kinds of things in a neat little way. And this all spawned from a project we called Volta back in Microsoft Live Labs, where we were trying to take C-sharp code, and you could compile it to JavaScript, you could compile it to Silverlight app, you could compile it to a desktop app, you could basically just doing the tier splitting and say, okay, this particular mouse movements, I want this to run on clients, I want this particular event to run on the server, etc. But the problem was that once again, with events, you can't really just pass events around, you want to pass this object, which encompasses this event. So we'll get into that to reactivax a little more further into the conversation.
But I want to talk about a term that you have made a point to enumerate, which is reactive programming. So what is reactive programming? The easiest way of describing that is readily responding to a stimulus, if you read the dictionary. But that's fairly simplistic in the fact that one could say in JavaScript all along, we've been doing reactive programming in the fact that we react to events, we add event listeners and we remove event listeners.
The idea though is being what I consider reactive programming is more of the compositional nature of dealing with events and dealing with callbacks in a very simplistic fashion, so that you can start chaining these kinds of things together in a way that you're not only responsive to any stimulus, but you're also responsive to the users making sure that when you're designing reactive applications that they're responsive to the users, they don't block, they can easily recover from failure. For example, if for example an Ajax call fails, how do you recover from that well-reactive programming is the idea that you're actually going to have a way to do that. So it's all about scale and really trying to take this whole paradigm of being event driven and really bringing it up to scale. And just to disavow us of the discussion of functional reactive programming or some other collection of buzzwords, what isn't reactive programming?
What isn't reactive programming? That's a good question. What isn't it? React is one of them.
React is. React from Facebook certainly isn't outside of its rendering. There's really not much reactive about it. It's doing the diffing and all that sort of thing, but in terms of a lot of the other things that they have, it's not really reactive, which is kind of disappointing as they've hijacked the term as it were, versus us who started out in 2009, 2010 time frame with our XJS and the whole idea of reactive.
So it's disappointing that some people have taken the name and gone off and said, okay, well, this is reactive. Now that's reactive. It's hard to pull that back really once it's been out there. Okay.
Well, so let's talk more about what reactive programming actually is. And one way is by virtue of example, you've told the story of companies like Netflix and Airbnb and Microsoft where you work, solving really big a synchronicity problems by changing how they think about events. Let's take Netflix, for example. What types of asynchronous problems does Netflix have to deal with?
Oh, any number of things. I mean, if you look at their player altogether, everything about it is asynchronous, whether it's their login, whether it's any of their animations, it's data binding, everything about it is completely asynchronous. So that's one of the things that they've had to deal with is this gigantic ball of events that they have to react to. Let's drill down into specific examples.
The first is the basic auto-complete that everybody loves to talk about. I'm sure there's a drinking game where people say, oh, auto-complete and reactive programming. But anyways, the basic idea of throttling the user's input while they're typing, just to make sure that they're not flooding your server with requests as they're typing. And you want to give them movies.
Well, that's certainly a thing to do, where you're basically making sure that they're only giving you unique inputs after a certain amount of time. And then you want to make sure that any previous requests that went out in between time to get canceled. So that's certainly one of those problems that they've solved. Another one of those is that they deal with very constrained devices.
So the idea is that you only want to keep on the page itself the data that you have. And once it goes out of scope, off the screen, then you want to clean up everything, deterministically clean up everything. And the good part about the observable pattern, what we have is certainly has the construction, but also the destruction, as it were. So I think that's a fairly important distinction there is that in reactive programming, especially the observable, is that we have the construction phase in which you start to yield values, but you also have the destruction of deterministically cleaning up.
So if, for example, I'm doing mouse drag, it's mouse down and mouse moved until mouse up. The idea of when you unsubscribe from that particular thing, everything gets cleaned up. Well, it's certainly the case here, where you're dealing with that, your user interfaces, you're basically adding a little bit of slack, basically, to be able to go up and down and not completely blow away everything. So it's a little bit of throttle there.
And then basically you're just going to start polling, as it were. And to make sure that when that particular row is now hidden, it goes away. And so it deterministically goes, OK, row, you're gone. And so those are kinds of the things that they have, and many other examples from managing web sockets and handling streaming data is definitely another one of those things that they do.
So that's one once again with the air recovery and so forth that our acts in the reactive paradigm really brings you in terms of dealing with scale and dealing with air handling, definitely helps you with. Yes. And we'll talk more about reactive acts. One of the features of reactive acts is that it has APIs built in a variety of languages.
And back in 2011, this set of asynchronous problems that we're talking about with Netflix, they didn't just feel it in their JavaScript. It was felt in six other languages. And each language thought of asynchronous in its own way, because the way that your language deals with asynchronous is born out of the constructs that are natural to that language. How did Netflix standardize the way of thinking about asynchronous across these languages?
OK. Well, the good news was that we worked very early on with one of the Netflix developers while he was still at Microsoft, Jafar, who's saying, and he was an early adopter of the stuff that we were doing with the Silver Lake Toolkit. He eventually went over to Netflix and really wanted to evangelize this particular work that he was like, this is awesome. It solves a lot of the problems that we're having.
And it was already written at .NETs and people who were doing a lot of event driven stuff were using the .NET version and eventually the JavaScript version. But the problem was, like you said, is that they had so many other languages that they were using from Skyled to Closure to Groovy and so forth. And they really wanted those kinds of paradigms to work for them. And as a side benefit to that, basically that one person could move from platform to platform.
But ultimately, if you're sticking with one paradigm, such as the Reactive Extensions paradigm, then really, you know the language that everyone speaks of, basically speaking the same DSL, regardless of platform. So they went ahead and created RxJava, which has definitely taken off in the JVM world, and especially in Android as well, which was really kind of cool to see is that people were dealing with a lot of party synchronous problems on their mobile devices. And so, well, that was the easiest thing to manage all of those kinds of concerns that they had. So once again, that was really one of the big saviors of everything is not only did it solve a lot of problems on the clients as we were talking about with mouse movements and all of that, but also to the server as well for a lot of really big server payloads that they had to deal with.
But once again, they were dealing with the same constructs that everybody else was. So they could take that job program or move from JavaScript, move into Groovy, and move to .NET. And they would all still be speaking the same language. As Netflix exemplifies, real time is everywhere.
No matter where we look in the stack, if we're looking at an Android device, if we're looking at a mobile phone, a web browser, a television, a JavaScript stack, everywhere we see asynchronous. Broadly speaking, what are some ways that we can think productively about the problems that asynchronous presents? Well, really, when you think about it, could you maybe you could break it down into this Zen-like moment as it were, everything as a stream. So if you consider every data source is a stream that can be composed together, then you start to realize that just about everything that you do is compositional and Lego-walked as it were, where you can start taking one and building it upon the other.
Anything from user inputs, whether it's touch events and dealing with data loading, all of those kinds of things are really all the same. They're just streams of data. And once you think of it that way, then you can start to construct them together and say, okay, these two things, I need to merge together. These two things, I need to compose together, I need to take the input from this one, pipe it into the input of this one.
So you're just starting to take these and start to build them together. So once you start to realize that all of your data sources, whether it's your mouse, whether it's your keyboard, whether it's your touch, whether it's a server, et cetera, are all data sources or streams that you can impose. And in your presentations, you often talk about node streams. What is a stream and node?
And how does that map to the conceptual presentation of a stream that you were just discussing? Well, node streams are fairly low level constructs. And really, what they're trying to do is more along the lines of buffers of data and to basically handle things like HTTP requests, any number of data source file streams and so forth. So it's really dealing with a low level construct and not really dealing with what I would say objects as it were that a lot of things like events are.
So a lot of people go, oh, I can put in an object mode and I can just use that kind of paradigm and all will be great. Well, it was a clumsy design in the first go around with the ideas is that data can start pumping to you before you're even ready. Or I, oh, geez, I added an end handler before I added the data handler and then just data started flowing it or I missed the data completely. So you're like, crap.
So that became very troublesome. And not only that, but pause and resume are purely optional in terms of, well, I tell you to pause, but it's up to the producer to say, well, I respect that, right? Don't. That was also a huge problem is so pause and resume really didn't work.
Data started flowing before you wanted it to. So in came streams too, which was was trying to do it in more of a push pool mechanism, which to me was interesting in the fact that basically you now have this readable events and then when readable came through, then you can start pulling and read, read, read until it was null and then start the whole process over again. So it was kind of that managing, managing things that way. But like I said, it's still not compositional.
In fact, it kind of is, but you only have one compositional piece, which is the pipe. And so you could take your stream, you could transform it into all uppercase, and then you can pipe it to the standard out. Yeah, that's fine. But for dealing with a lot more complex things that we deal with, especially in user interfaces and so forth, it requires a lot more, requires a lot more ways of composition than type.
So you're saying that the low level concept of node streams, these are not a high level enough abstraction to achieve this Zen-like streaming notion that we want to move towards. So let's move towards the idea of events. So just thinking about programming in terms of events, make asynchronous programming easier. Events, I would certainly say data sources and events being certainly one of those kinds of things, absolutely.
And typically, like I said, the event composition has been very hard, whether you've got raised conditions about which event happens first. Any number of those kinds of things are very, very difficult to manage. But yeah, when you start to think of everything, all your events, everything else as streams, and that these streams are compositional in nature, then yes, you pretty much have that reactive mindset now. And you draw an interesting parallel between events and arrays, and you stress that these are both collections.
So if I'm completely new to JavaScript, and I hear that statement that events and arrays are both collections, that might sound kind of strange. I understand how an array is a collection, but why are events a collection? Why can't they be? That's a very good question.
But basically what you have is an array, or even a generator is a finite or infinite sequence of values that you basically pull from, whether it's by index or just calling for each and all of that. And even in case of generators, you're calling next and getting the values. But ultimately, it's still, you know, blocking and getting new values. Why can't we think of mouse movements of keyboard events in the same kind of way that even your mouse, what we used to call our talks was your mouse is a database.
And it's very true is that your mouse is a collection of mouse movements, mouse clicks, everything about it is a collection. But that is not pool based, but instead is push based. So we kind of draw that parallel between the two, and what we call, and what we were enforcing in our earlier talks about the duality between two is you have your pull collections over here, and you have your push collections over here. And if you understand one paradigm, when especially with ES5 and the array extras, when the map filter is reduced and so forth, well, you suddenly say you understood that, you're like, oh, map and filter and for each, I get that, that makes a lot of sense.
And then you go over here, and then you look at mouse movements, you're like, oh geez, I can do that, I can do a map and I can do a filter, and I can subscribe. Well, that's kind of neat, is the fact that you really don't have to change any of the code, you suddenly have taken this array of, you could say, you take some array of data, on once you could say take some data that's pool based and push based, and the code would be absolutely identical in terms of how people would actually process it. So you've said that the vast majority of functional programming at Netflix, for example, is done with just a few commands, like map, filter, and flat map. Map and filter are more well known than flat map, but could you just define how all three of these functions works?
Sure. So map is a very simple construct. I won't get into any of the whole monoids and functor stuff, so you don't have to worry about that, thankfully. And I should really want to go there in terms of category theory and everything else, but let's not.
So the idea basically of a map is the idea is you take each individual value, and you transform it given the function that you're given. So for example, I can say, take a stream and take each value and multiply it by two. Okay, so then it produces a new stream on the other side with those particular values that are now multiplied by two. So that's a very easy, you know, quick transform.
It doesn't modify the existing collection. It projects it to a new collection, each individual new item being multiplied by two. Now filter, on the other hand, is more of a reduction operator. So for example, if we take a particular stream of data once again, some numbers, and we only want to get the numbers that are prime out of that, well, we would have to write a filter basically that takes an input and decides whether it's prime or not.
And if it happens to be prime, on the other side of the, you'll get a new collection, only containing the ones that are prime and everything else is dropped on the floor. Now, flat map is very interesting. It's a very interesting thing to talk about because it kind of varies from paradigm to paradigm. But let's talk about it in terms of arrays.
So the basic idea would be to once again map the data, but you're going to map it to a particular type, whatever type you happen to be. And so for example, if you're an array, you will do an array dot map, and you will return an array from that array dot map function that you had inside. Now you have array of an arrays. Okay.
So now you need to flatten it in some sort of way. So basically, you would just basically unfurl it as it were into a single collection. And so basically, you could think of it as nested for loops. So you're doing for item in items and then you go project to the other collection through the function that you pass in.
Now you've got this, once again, you have this Cartesian product as it were, just going from one loop to the other loop. And then you're basically getting a result there. And then you're just flattening it into a single thing. In observables, it's really no different in the fact that it's a map than a flatten.
So you could call it map flat if you really want to, but the idea is that it's going to map it and then flatten it. And the mechanism that it uses, say in observables, is slightly different in the fact that you've got, as we talked about with arrays and observables are being collections, well, observables add that notion of time associated with it. For example, not all your mouse movements happen at once. Not all your keystrokes happen at once.
So it's collections over time. And so when you're thinking about collections over time, then your flattening is going to be slightly different because now your flattening is going to be basically a merge instead of a concatenation onto each other. It's going to be more of a merge and saying this keyboard happened here, this one happened here. And so it starts interleaving them based upon the time that they actually occurred.
So this discussion of map and filter and flat map functional programming, how does this tie into the idea of reactive programming? Well, the idea here, how it ties in is those are kinds of the mechanisms that we have to do combining of streams together or to start doing compositional behavior of streams and to say, okay, I really only want the mouse movements when it's in this particular bounding box. I only want these particular key events and nothing else. So if it's any of these keys, then great, send it through.
So all of those sorts of things have everything to do with reactive programming and then things like flat map and all the other operations that you have are really about combining things. So for example, I have the example in a lot of my presentations of showing some code that you do filtering movies basically using flat map, basically taking the user's videos, video lists, and going down to the videos where the top rating is five and giving me all of those movies. Well, it was the same kind of thing with mouse tracks where you take your mouse downs and then your mouse moves. So it's mouse down dot flat mouse move.
And so that filter that we had before we have a different combinator or method that we use to combine and that's taken till and taken till basically goes, okay, keep listening to mouse movements until mouse up happens. And then suddenly the stream is terminated at that point. So now every time mouse goes down and the mouse moves, you keep on doing something, you keep moving around. And then when the mouse goes up, it terminates the stream.
At Microsoft, you have been working on reactive x. What is reactive x? Okay, well, reactive x or reactive extensions is basically a family of, of, of, I would say technologies or libraries, as it were, that's that built upon this observable paradigm. And it's spread throughout, like I said, it started back in the mid 2000s with the project vaults of the idea that we can do this, this tier splitting and what we call the link to events, which suddenly became the reactive extension.
So it kind of makes sense where it's language integrated query for events. And so we're like, well, this is great. Now we can take this whole paradigm since it's just code and move it to any language we wanted to. And so JavaScript was, you know, very much the natural places to go, especially as we were very forward thinking at the time versus, you know, a lot of people were investing in Silverlight, we were like, we're going down the JavaScript way and we're going to, you know, pioneer this way of doing reactive programming because nobody else has really done it before.
And like I said, when we started, there really wasn't any notion of promises either. So we're like, well, you can use this for promises as well, you know, single value, multiple value, it doesn't really matter. And so that whole idea has spread pretty much throughout the company, whether it was in stream insight dealing with streaming data, whether it's being in Cortana, which uses it really at scales, not many people see before and office and plenty of other products along the way. But all in all, it's just a family of languages that all implement the same paradigm.
And we all kind of group together and make sure all our documentation is, you know, everything that we're doing follows the same idea so that you can go from one, one language to the other and get the same results that you would expect all the way through. So Microsoft and Slack and Netflix and all these other companies are using ReactiveX under different domains. Could you give an example or two about how one of these companies is using ReactiveX? Sure.
So like I said, Delve, Microsoft Delve, they were certainly a good user of it. And it's a lot of the things that they do for animations, a lot of the things we do for once again, auto complete scenarios that they're using it for Slack. On the other hands, they're using it for a lot of, for example, spelling suggestions and spelling corrections that you're doing along the way. Because once again, your keyboard events are once again, just streams.
So if you could start reading it as it comes through, recognize the language and then just start offering suggestions of like, oh, this person typed in T-E-H when they meant it's typed in T-H-E. Let's correct that. So those kinds of things that they can kind of do right on the fly is very, very neat. So once again, when you're dealing with something that's largely textual based, you want something that can do the analysis along the way and make corrections as necessary.
ReactiveX has the tagline, the observer pattern done right. In what ways has the observer pattern been done wrong in the past? Okay. Well, if you take a look at the way that the subject observer pattern and its associates have been done is for example in Ruby and in Java, you'll see something that's fairly wrong, I think.
And quite honestly, I think it's also in even in DOM events. And the idea there is basically that you have this monolithic, observable or subject as it were. This goes back to the Gang of Four pattern, where you have this monolithic object or producer of events and then you have all the, this monolithic objects knowing about each and every one of your subscribers and then as data comes in, you basically do a for loop over each one of them and notify them along the way. But once again, like I said, that's not compositional.
You're dealing with the fact that this whole thing has to know about all of its consumers, all of its, sorry, all of its producers. You can't really compose those two things together very well. I can't say this subject and this subject combine those two. Well, there rarely wasn't any mechanism to do that in the language itself.
So what we did is we took that pattern and said, well, it's not really compositional as the way it goes there. Instead, let's build it very functionally. So instead of this subject observer pattern having this monolithic subject where it knows about everything, we will start to basically chain these observables together and basically so that you can take this one source of data. You can do a map that creates a new one.
You can do a filter that creates a new one. You can do scan that creates a new one. You know, all of these sorts of things and none of them particularly know about their consumers at all and that they're very, very compositional. So I can take any part of that particular chain and subscribe to that particular part of it.
So once again, you get highly compartmentalized, you get the compositional behavior out of it and it's not like the plain old subject observer pattern where you just have your basically add and remove. That was also the downfall and the real bad part about the compositional behavior is the fact that you're a particular subject. You had to tell your observer had to say when I wanted to stop listening to, but basically handing back that observer and say, hey, remove me. So what we did on the other hand, to make it compositional, is the fact that when you call subscribe, we hand you back this way of unsubscribing.
So basically, as we go along, we're building up these chains by handing you back your subscription object and say, okay, well, when you want to get rid of it, just call dispose on it. And so you can start building them up, building them up, building them up and then you have this big gigantic, you know, subscription or chain subscriptions as it were that when you call dispose, it completely goes up and down the chain and make sure that everything else is cleaned up and all the handlers are removed. And once again, if you have the add and remove directly on the observable or subject itself, you can't really do the combining behavior more along the lines versus the, we actually hand you back the logic that cleans up as soon as you call subscribe. So how does the observable pattern compare to the iterable pattern?
Okay. Well, the iterable pattern we saw very early became a pretty big success in dot nets with enumerable T and back in 2005, they came out with language and grade aquari, which started to add all these functional programming constructs. Our founder Eric Meyer, he was one of those key people in there. He also goes back and is very involved with Haskell and the early days of Haskell and including the Haskell 98 report and so forth.
So we were looking at those particular things and we were enamored with this link thing. We could linkify the world, meaning we could turn everything and query just about everything. And so then when it came to doing the web and UI programming we were like, well, dealing with events, this is terrible. Couldn't we think about these iterable collections and these observables and these events is the same thing.
So we started doing the mental mapping between the two. And in JavaScript, you can even see this today. When you, for example, call subscribe, you're basically given this object as it were. But you've passed in this observer.
And this observer has three basic things that you have with it. Next, when you get new values, error whenever an error happens and completed when you happen to be done. On the iterable side, you get the iterator you can call next. And so next we'll tell you, we'll give you the value.
So you know, obviously it'll give you next or it'll give or it will tell you what's done. Alternatively, if you call next, it could also throw an error. So at a certain point, we just saw this kind of connection between these three things where you say you get a value, you get an error, you get a completed. We're like, map those one to one and said, okay, well, let's create an object that's called with the observer.
And sure enough, it handles all three of those particular conditions. I want to talk some about how you manage reactive extra. What the project has evolved into in terms of this, you know, a project that has work being done by Microsoft and I think Google and plenty of other companies. So what is it like participating in an open source project with with so many different big influential players?
It certainly is a new adventure every day for sure. Because as new languages come in, they really want to understand the very basics of how they would implement something. That's always a good challenge to deal with making sure that we're consistent from language to language to language. Map means the same thing, filter means the same thing, and so on and so forth.
But not only that, but you have a lot of people trying to specialize these particular frameworks to do various things based upon their particular workload. So for example, when Netflix started to come into the picture, they wanted new operators. They're like, well, the ones that you have right now don't really work. Let's try to add these things in there.
And oh yeah, we're on every single device. So we need to squeeze a lot of performance out of that. So sometimes like all open source projects, things can be contentious. But at the end of the day, we all respect each other and say, well, and say, well, differing opinions, that's a good thing.
We just need to explore them all and make sure that we've got the right answer, making sure there's no regressions. We're not breaking anybody and so forth. But yes, there are certainly a lot of personalities involved, especially as you're dealing with people from Google, from Netflix, from Microsoft, from any number of GitHub and any number of other companies that are using it today. And now it's taking a life onto its own, especially in the JavaScript world when it's starting to be included with Angular 2 as well.
So once again, you're dealing with a lot bigger scale than it ever had been before in terms of being more of a peripheral technology where you would sprinkle it in to use with your libraries as you wish to becoming a core fundamental part of a particular library. What's the future of ReactiveX? I think it's very bright in the fact that we're starting to see new languages pop up all the time. So we got PHP's implementation is now in our mainline organization.
And we have one particular person who now works at Facebook wrote it as a hack project, but now we actually have people that are contributing to it and making it pretty awesome. On the RxJS side, we've got basically a rewrite because there were performance concerns and a number of other modularity concerns that we had along the way. And not only that, but dealing with a fairly complicated library sometimes requires a little bit of typing. So TypeScript was one of those things that came into the picture.
So in particular, we're working with Netflix engineers. We're working with a good number of good people there, Andre Madaros, and as well, other personalities outside of their Paul Taylor bin, people like Jeff Cross, Rob Wormorld, all of those people are just, and then we've, you know, too many OJ-Quan. All these people are just, you know, too many to mention off the top of my head of people that I just see check in after check in after check in every single day on the new version is really, really heartening us about that. They're a very focused on performance and b very focused on making sure that it's right and working on everything in terms of growing the community, answering questions and so forth.
It definitely has a huge impact, you know, obviously in Angular 2, but I think also in places like React, obviously, for things like replacing Flux or replacing even some of the core parts of React itself, instead of the whole set state stuff, you can actually have your whole state as observable itself. So all of those kinds of things that you can basically do with it are very, very interesting. And then taking it further, you could, like I said, a lot of frameworks out there that are new that are coming onto the scene you have, Cycle.js, which is a, starting to get very popular with people doing reactive programming who want to really embrace the observable style of doing programming, especially kind of focusing on a new architecture, model of view and tent architecture. I think it's very, very cool and very, very, very, very innovative stuff that I'm seeing there.
And so it's basically combining, you know, the technologies of observables with the virtual DOM and you've got this whole new paradigm of thinking. And then you've got another one called Yoke.js and then you've got WebRx. So none of that ever seems to be going away. I mean, there's a new idea every single day.
It's just hard to keep up sometimes. With .NET, we're focusing on getting 2.3 out the door and then seeing what we can do in the future in terms of taking what has been done with Cortana and making it available and say, hey, if you really want to use the reactive extensions at scale, here's how you do it. And then there are, of course, other languages that we want to tackle fully, whether it's Ruby, Roscoe, et cetera, to see how they really play in a particular space because I think it just has lots and lots of room to grow. And even in JavaScript, it has a lot of room to grow, especially as Jafar Hussein, who, like I said, worked with us in the early days, is now a TC39 member.
And he is working on standardizing along with Kevin Smith on standardizing the observable as a first-class object in the JavaScript language itself. So once again, here's here, it's mind-blowing just in terms of how much influence it's getting. Well, that's a great place to close off. Matt Podbysoski, thanks for coming up with Software Engineering Daily.
It's been great talking to you. All right. Thank you very much.