 Matthew works at Microsoft. He's been working on reactive extensions for JavaScript there since about 2010, and it's time to get some exciting traction now. So he's here to talk about that. I know he's really excited about it. So let's give him, oh, do we have it ready? I suddenly realized there's technical fun going on. Are we good, Matthew? Brilliant. Let's give him out of here all welcome. All right. Oh, everyone, I guess I have the unfortunate position to be right next to lunch. So I guess I will keep this quick. So today, really, if you want to follow along, you can already go there, download the slides, download the code, and you're ready to go. I am Matthew Putnasotsky, or in America, Matthew Podwosaki, and very un-originally on the internet, Matt Podwosaki. We also tweet at ReactiveX. So really, what is this talk about? Well, like I said, it was about stream programming, or how I stopped worrying about asynchronous programming and started to love the observable. And no, this is not going to be a Monad tutorial. There are no going to be advanced functional programming techniques. If you've seen my former boss, Eric Meyer, he loves to talk about Monads and duality and everything else, I can't quite frankly stand that stuff because, well, it doesn't help you. Now, reactive programming has actually been a fairly hot topic lately. How many people actually took the Coursera course on reactive programming that was done very recently? Anyone? All right, absolutely nobody. This is great. Anyways, so the reactive manifesto was an idea that we could codify an idea of what exactly is reactive programming. So the dictionary gives us this definition that says, well, we readily respond to stimulus. Well, that's not really all that useful because, well, if I set a variable, that's responding to a stimulus. So what does it really actually mean? Well, what it means is that I react to events. So normal things that you do in your JavaScript applications, you react to events. That's what you do. You don't have a choice. It's like when I want to mouse click, well, you react to events. But in addition, there are other things that you might have to take into consideration, such as load. So how do I take my load? And I say, well, maybe my system can get overloaded. That's bad. Also, in addition, just because we are fairly reactive, we also have to be reactive in terms of reacting to failure. And we also have to be responsive to users. How many times have you launched an application and the beach ball just sits there in turns forever and ever? That's not really reactive. That's just your block from doing anything potentially useful. So quite honestly, this whole talk is really about stream processing. Now, when we talk about streams, what do we really mean? Well, there are a lot of different ways of thinking about streams. For example, Node has this idea of streams. So anything that's IO related, whether it's HTTP, TCP, file IO, et cetera, are streams. But it's more along the lines of binary streams. So quite honestly, it's not very interesting to me. Because it does support objects or arbitrary objects, but it doesn't do a very good job at that. And composition is kind of terrible. In addition, they're trying to take the ideas. And since this is future JS, they are taking streams and moving them forward as an idea for abstracting IO for the entire, well, that's special. All right, they're trying to standardize all of this. But unfortunately, they're leaving out a very important part of what makes streams very, very interesting and very valuable. So there's a programming language called Dart. I'm sure someone's heard of at some point. All right, this is getting annoying. And so what Dart decided to do was actually wholesale lock, stock, and barrel pick up our design from the reactive extensions and unify it across file IO. Yes, all right. And file IO and events, so that they're really the same thing. You don't have to distinguish between the two. Unfortunately, they've made a few decisions that I don't like. For example, that if it's a scalar value, such as a reduced function, et cetera, it returns a future. Well, the problem with that is it's not really compositional in nature, because now you can't just assume everything is going to be a stream. Now you have to say it's a stream, or it's a promise, and it gets ugly really quickly. Now what's the point of the reactive extensions, the thing that I work on? Well, real-time data is everywhere right now. I mean, you have your phone, you have your tablets, you have whatever, and you're constantly getting notifications. And it could be from any number of things. It could be you're following the stocks, it could be your RSS, it could be servers, it could be UI events, social media, everything like that. And it's very much a push-based world. But how do you unify it all? The problem is that each and every one of these things has a different kind of interface on how you actually deal with all of those. But the point of the reactive extensions is to unify that into a single concept, the observable. And so that's why when we can now, say, take something like the Netflix API, also Netflix is a heavy user of Rx. And we can now start to query the top-rated movie collections. And if you look at this code, and you're very familiar with programming with arrays and JavaScript, this code should look fairly similar to you. Because you're dealing with map, and you're dealing with filter. Instead of for each, you're calling subscribe. It's a very, very simple code. What we're doing at the end is we're saying merge all into a single list. So what we're trying to do is go through the video list, get the videos where the rating is the five, and flatten it into a single list. Now what if I could tell you that the same code you just saw could also create a mouse drag event without really much change? So let's go take a look at that. What would it be? Well, what it would be is that we would take mouse down. So for example, if element exposes mouse downs, we can map there to take mouse moves. And then instead of doing a filter, we say take until the mouse up happens, and then merge all once again. So let's take a look at that code again. This and that. Do you really see much difference? The answer is no. Because ultimately, we're doing a very nice compositional matter, no matter where the source happens to come from. It could come from a web socket. It could come from an event. It could be an XHR, you really don't have to care. Either way, you have a unified programming model about it. So I don't know about you, but a lot of people just said that when I explained it that way. Now I'm sure everyone in this room has faced callback hell at one point or another. Why? It's just a fact of life. Anything that's input, output-based, event-based, et cetera, you have callbacks. Node is particularly notorious for this, especially with their error-first style of callbacks. And so composition becomes really kind of difficult to reason about really quickly. And then what happens is, instead of this very linear style of trying to get work done, your logic gets very lost in there, because you're trying to figure out where exactly my logic is versus where my error propagation is. So what you end up with is a cow head, basically, in which your code just starts to look like it's starting to creep off the screen, or just look like a cow's head, one or the other. So let's face it. Asynchronous programming is annoying. There's no way of sweetening it. Each framework that you deal with, and each runtime that you deal with, has a different way of dealing with callbacks, events, et cetera. You have Node has callbacks, then we have promises, then we have events. But each concept is really only part of the story, right? Because callbacks are certainly useful for file I.O. and things like that. Streams are another part. And then events are completely other parts. But it's only part of the story. Instead, wouldn't it be nice if we actually had something to combine them all into one? So let's actually take a look at a few examples of some reactive applications in practice. Now, we'll take a look here. For example, game programming. OK, not showing up. Let's see. Can you see that now? Area. So let's go back and take a look here at game programming. What is really game programming all about here? Well, game programming is really all about I can react to events. I have timer loops. I can start to interact with the screen here. I've got boundary checking. I've got any number of things. And I need to be very deterministic in my behavior. It's kind of a perfect metaphor for dealing with reactive style applications. So as you can see, I lost because I just didn't care anymore. Now, there are other particular things where actually it's fairly interesting. When you're writing real-time applications, it's really kind of let's see if we can refresh this and see what happens. Beautiful. So when you're dealing with real-time data, so for example, I'm dealing with stock trading, what you really want to know is you want to know quickly, as quickly as possible, when do I need to sell or when do I need to buy certain stocks or when do I need to buy and sell currency exchanges. That kind of information is another kind of style that reactive applications are really, really good at. Because what we're dealing with is we're dealing with that real-time data and we're dealing in a query model so that we can start doing some very rich things. And what you saw, you may have seen at several points, is things go red. Well, that's error handling that we take care of automatically. Perfect. Another one. So let's see. This one is finding ninjas around you. So let's say, for example, I want to say Barcelona, Spain, and I want to find JavaScript people. No, not Java people. And what this is is a basic autocomplete kind of scenario that will go into how you actually do that. But as you can see, it's taking a while. But maybe because there are a lot of JavaScript people here in Barcelona, hopefully. Moving on. Maybe it'll come back to me one of these days. So let's see. Well, to-dos. Everyone has a to-do MVC example. Well, here we have just the same. Hopefully, let's see. Do well in my talk. I don't know if I'm going to do that. So let's say, hope. Let's add a new one. Hope not to fail. All right. Perfect. All right, good. Now, all of these things are using the reactive extensions along with things like React, whether they're also, for example, in this particular example here, was using Angular. And apparently, I need to just refresh this because this wasn't working. So Barcelona, Spain, oh, perfect. Now, I want JavaScript. And nobody here knows JavaScript. This is really kind of sad. There we are. We know some Java people here. Perfect. Anyways, so also, drag and drop, fairly, fairly simple. We'll get into actually what that code actually looks like in just a little bit. But even still, stupid little things like simple animations are really, really easy to take care of in a reactive style. So once again, you're kind of dealing with one that's delayed. Then you have one that's delayed on top of the other one and then adds a little bit of a wag to it. And not much code actually had to be damaged to do that. In fact, if you take a look at mouse three, not much code. I just basically, for the wagging, I just basically go in there, say, delayed times five, set the wagging for the top and bottom, boom, done. It's all completely, as you can see, a very fluent coding style. So let's actually go back and continue here. So from the current slide, yay. All right. Now, when we're dealing with normal programming, what do we usually do? Well, we're dealing with normal style collections. So for example, we would go ahead and iterate through a collection. We would do something on when we get an item, when we handle an exception. And then optionally do something when we're completed. Well, that doesn't really work all that well in the async world because, well, it doesn't work that way because you have to have callbacks or events or handlers and so on, et cetera. Well, what we just saw was the iterator pattern there. And that comes from this gang of four book, which I'll date myself. I actually have a copy of it, and it's from 1994. So if other people have it, then you're probably dating yourself, too. But what they also had was this notion of the subject observer pattern. And then they never really connected the dots here because the subject observer pattern is something that you deal with almost every day in your JavaScript code. For example, adding an event listener and removing an event listener. That's kind of the observer pattern because your document or whatever is the observer. And then you have your functions, which are rather the document is the subject. And the observers are just the functions. Now what we decided to do was take a little bit different angle and say, all right, well, now let's take the idea of the iterator pattern and make it push-based. So we can say, all right, from event on a particular element, on click. And then what we can do is create an observer, which basically does the same thing as encapsulating what was inside that for loop and then capturing the errors and capturing the completion, all three of those. Now what you'll also notice is that we can call subscribe at the very end. And what does that give us exactly? Well, it gives us the idea that we can deterministically throughout our application clean up entirely. I don't know how many people have dealt with this, but when you're dealing with event handlers and you're leaving them around, that's a memory leak. And especially if you even start removing items from the DOM, it's still a pretty bad leak. Well, in this particular case here, when we just call dispose, boom. I unhook those event handlers for you. And then when you start to combine them with other events, well, just because you have just one event, well, maybe now you have five events, well, when I start to combine them all together, when I call dispose, that gets rid of all of them. So there are no chances of memory leaks at all. In fact, the folks at Netflix have never really had to physically call unsubscribe from an event. And we have a very, very strict kind of way of talking about it. We have the on next, on error, and on completed, where you can have zero to infinite numbers of on next calls followed by an on error or uncompleted. So for example, here, we can go have one, two, and keep going for infinitely times. We can also go a couple and have an error. We can also go have two values and stop. But what we can never happen is we can't have two overlapping callbacks, and then something happened after the fact. That just can't happen. And so what really is one of the key components of RX and things that are like RX is now that we've encapsulated events and XHRs and everything else into a first class object. So now a mouse move is actually an object of a mouse event ARDS. You can have mouse clicks also as an object that you can just start passing around. What makes it first class is when it's passed into a function or returned from a function. And what you get from that is that you can now easily swap in and out parts of your application really nicely for testability purposes. I can substitute this observable sequence for this observable sequence you'll never know. It's the same object. Unlike events, you can't do that. But for observables, you absolutely can because it's wonderful, wonderful for testing. And I'll show you exactly how that is. We have, for example, 1,800 unit tests for this particular library. Yes, it sounds like a lot, but, well, asynchronous programming A is annoying and B hard. So what we already talked about is the observer and the observable. So RX, in essence, is three main concepts. You have the observer and the observable, which I've but we also have query operators, like map, filter, and reduce that you're already used to if you're using array style programming inside of JavaScript. So if you're using all of ES5's array extras, you already know how to do this. This shouldn't be very hard to you. And finally, we'll talk about schedulers, which is probably one of the more interesting parts. So RX is everywhere, really. We have a number of languages that we support, not just JavaScript. So for example, we have Ruby, PHP, Dart, Objective-C, Java, .NET, C++, any number of those in varying levels of maturity. But what we've shown is the fact that it actually translates very, very well to just about any runtime. And what companies such as Netflix has really found is that since they created RX Java, is that they can take the UI folks that are doing JavaScript and shift them over to doing Java or to Groovy. And there really isn't any transition period necessary. Why? Because they speak the same language. And that language is RX. So when we talk about these higher order operators that we have, well, we like to first talk about in marble diagrams. What we do is we have kind of the two things, the dots and the results. So for example, if I want to filter out things that are in my collection, I just simply call filter. And in this case, we'll have dots that we want to only want the orange one. So in here, we're not actually mutating the existing event stream. We're creating a new event stream. In addition, with map, you can do the same concept. We can say, I want to take the circles and turn them into triangles. And all I had to do was just call map. Since that's all well and good, but since we're dealing with a notion of time, because observables are really a notion of values over time. And so what we can do is we can say delay by one second and sure enough, as each item comes through, it's delayed by a second, retaining its original spacing in between. So we don't want to necessarily say, OK, we're only going to space them one second apart. No, no, no, this is we just physically shifted the time completely. And all you had to do was say delay 1,000. Now let's really talk about the asynchronous programming landscape. Now for the perfectly synchronous value, you just have whatever value you call, whether it's a function, whether it's a value, et cetera. Now when you're dealing with arrays, what do you do? Well, you can say filter. You can say map. And then you can four over the loop or four each over the loop. And you're good to go. Nice. Now what we also have in most libraries is we have the idea of promises. Promises are great for a single value computations that are asynchronous so that I can start to chain together things such as XHR requests or any number of things. I can just start to chain them together using them. But what do we have for that kind of fourth quadrant? Well, we have the observable. And the observable is the piece that really is the kind of the secret sauce that actually can span all of them. Oh my god. All right. So now let's actually go back to the mouse move event that we had before. Now what we're going to do is we're going to say, all right, we're going to take our mouse downs wherever they come from. We're going to then say combine them, right? Perfect. We're going to start combining them with the mouse moves mapping from the differentials between the top and the bottom. Like I just said, this is beautiful. And then what happens? Well, this is great. Now we've taken the mouse downs and the mouse moves. But the problem is that we need to now say, mouse up is the thing that terminates it. And the beauty of that is that it goes up and cleans up the entire mouse move thing. And it terminates it deterministically. So you now have perfectly described what mouse drag is. It's mouse down and mouse move until mouse up. You're literally saying that right here in the code. Now, in addition, just because we're dealing with promises as well, let's go back to the autocomplete kind of scenario that we were talking about earlier. Is what we're doing is we're typing in and getting the key up event as we get them. Now, I don't know about you, but the last thing I'd want to do if I'm a really fast typer is send every single request to my web service, because my Amazon or Azure bill will be quite huge after a while. So how do you really take care of that? Time is money and bandwidth is money here. And then all we want to do is come back and we want to get those observable array of words. How do you do that? Well, once again, we can get the key up, and then we can project through, get our value. Now, we can say throttle it. So for example, if I keep continuing to type and then I pause for half a second, it's going to say, ah, good. You've stopped for a little bit. I'm good to go. But not only that, but I could still keep on typing and hitting the arrows left and right. Well, that's still a key up. And the problem with that is that I don't want that data. I only want it when the text actually physically changes. So what I always call distinct until changed. And then what we're going to want to do now is deal with one of the most difficult parts of asynchronous programming that many people ever look. And what is that? Out of order search results. It is not deterministic at any point in asynchronous programming that I can call React. And I can call reactive and make sure that React gets canceled and I only get reactive. It's not deterministic at all. I could type in React, then reactive. Reactive comes back first. And then after that, React comes and it clobbers all of my results. That's the last thing you'd want to happen, but I'd seen so many times. Well, we already have an operator that kind of takes care of that. So we get the latest response and then we cancel the previous request if at all humanly possible. So now you don't have to worry about any of that at all. It's taken care of for you. And then you can just take the words and subscribe to it as you normally would. Pretty simple concept. But let's go a little bit further. How many of you people are familiar with the company called Netflix? So Netflix, since I work quite deeply with them, they have a very specific problem. They have to deal with a number of form factors that are kind of memory limited. How do you make sure that what you load in your UI is actually fairly under control in terms of I'm not loading the entire thing. I'm only loading what's in view and I'm getting rid of the rest. How do you do that? Well, what you can do is you can start by throttling it through the scroll event and then determining whether it's visible or not. And then start to pull each individual time getting that row data until that row is hidden. And when that row is hidden, boom, it's gone. It's gone from memory. It's removed from the DOM. All of the event handlers are detached. So all of those particular things taken care of for you. This is huge for them because now they've got a way of easily determining whether things are visible or not. And so if they've got a really low-end device or even high-end device, they're still very, very responsive and memory conscious. Now, the last thing I wanna really talk about here is this notion of how to parameterize concurrency. And it's actually a fairly interesting thing because where do you actually wanna run a timer? So for example, I might wanna run a computation completely synchronous. Well, I can do that. Or I can decide that I want to use a process next tick for when it's scheduling or any number of things. I wanna put it on a set immediate where I wanna use a mutation observer. Any number of those things, I get to choose. And that's the beauty of it. And not only that, but the schedulers are the answer so that at any point in the computation, I can switch between whether it's doing it on the immediate, doing it immediately to when it's doing it in the background. And which also provides you with a lot of testing benefits as well because once again, I can intercept all of those calls throughout and say, aha, I'm going to decide when those get executed. So you have many implementations of this and you can say optional time. And then you just asynchronously do your work and then have deterministic cancellation that flows completely throughout the system. So let's say for example, I wanna test if future JS is awesome and I hope to God it is. So we can say we get a sequence in of at 300 ticks, we have future JS and at 400 ticks, we have 2014. Then what we can do is we can start our scheduler, run it through, map each value to get the length out. And then what we do is we say, okay, deterministically at the end, we can say what messages came through. Here we had at 300 ticks a length of eight and at 400 ticks a length of four and at 500, we know that our particular sequence terminated. How easy is that? In fact, that's how we write all of our tests in our X. Each and every one of those completely non-balking, even though it's an asynchronous framework, we don't have to physically do anything to make it really special is the fact that we've got all of this here. We don't have to overwrite set time out or anything. We've got this way of just weaving it through entirely. So once again, we open sourced all of this stuff. It's available on the GitHub. Now where are we going? So I showed you a lot of really interesting examples. Where are we going with this? Because since this is future JS, we're supposed to be thinking about the future. Now there are certain things that we want to tackle, such as back pressure. The idea here is the fact that somehow the events are coming in too fast. You know, you can throttle them, you can do any number of things. But what if I don't want to lose any of them at all? I don't want to drop them on the floor. Well, I can do that by using notions of back pressure. The way nodes solved it was far from ideal because they're dealing with single producer and single consumer. We can't necessarily assume that. So we're actually working with the community to do that. And in fact, there's an effort called reactive streams. They save for the JVM, but really that's a lie. It's for everyone who wants to participate in this particular thing. So we're working with the Aka folks and so forth to really kind of come up with a nice, consistent design for doing object-based back pressure. And just as well, just because I like generators and generators are very cool, what I'm also working on is the fact that now what we can do is we can treat observables as yieldables. So in here, I can yield getting some stocks from a server and I can retry it three times automatically in line. And if I get an answer grade, else it throws an exception. And then I can get the length or I can go out there and do a try-catch on an invalid host. All of that using the yield functionality within generators. So once again, you'll get a nice linear style. So if you really want to get more of the imperative linear style of code, using observables, it just works. So that's where we're going with that. So like I said, we are just a three tier model basically. We've got a lot of really cool stuff out there on GitHub. So if you really want to check us out, we are also at ReactiveX and so forth. So with that, I'm not sure there's sound in here, but so in the meantime, I will just let you ask a particular question. So I'm opening the floor. I just wanted to ask if you're familiar with Highland.js library and Highland.js. Highland, yes. And if you are, I just wanted to know what, is it similar or is it different? It is similar. We have, Callan McMahon and I have violent disagreements as to which approach is right. But that's a good thing because it's a healthy debate. What he's trying to do is trying to meld a lot of very node-centric style in the browser, which I don't agree with necessarily. I like to keep mine very pure, very mathematical model. He is more along the lines of it's going to look kind of like node. I want the full chaining APIs. It's not as easy to do that in Highland as it is with RX. Not only that, but we have 60, 70 operators that you can deal with at any particular time, all completely testable. So Highland is a great effort. I may disagree with it, but in terms of some of the design things, but I see more libraries the better out there because that'll flush out a better design for all of us. Thank you. Anymore? No, great. Thank you very much Matthew. Thank you.