02:19 - Matthew Podwysocki Introduction

04:01 - RxJS

10:18 - Practical Experience of Use

17:28 - observable-spec

21:43 - Observables and Promises

25:06 - Using RxJS in Common Frameworks

27:53 - Are there places where observables might not be better than callbacks/Promises?

29:16 - Why would someone use RxJS on the backend in place of Node streams? 

32:28 - Are Promises dying?

36:13 - Observable Gotchas

40:29 - Influence

47:47 - Will observables in ES2016 replace RxJS?

Picks

A cartoon guide to Flux (Aimee)
Promisees (Aimee)
The Dear Hunter - Act IV Rebirth in Reprise (Jamison)
Jessie Char: Expert On Nothing @ NSConf7 (Jamison)
XHR Breakpoints (Dave)
Glove and Boots (Dave)
Computer Programming (Joe)
Evan Czaplicki’s Thesis for Elm (Joe)
The Alchemist by Paulo Coelho (Chuck)
thaliproject (Matthew)
BBC Micro Bit (Matthew)
Minutemen (Matthew)

Special Guest: Matthew Podwysocki.

 

Hey everybody and welcome to episode 182 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance.

Hello, friends.

Aimee Knight.

Hello.

Dave Smith.

Greetings from beautiful Lviv, Ukraine.

You're in Ukraine?

Yup. That wasn't just for show.

I'm Charles Max Wood from DevChat.tv. And this week we have a special guest and that's Matthew Podwysocki.

Hello, everyone.

Do you want to introduce yourself?

Yeah. So, I am a Principal SDE or Software Developer Engineer at this small startup in Redmond called Microsoft. And…

Never heard of it.

I know. We didn't even have any announcements today. It was kind of sad. Anyway, I am a selfdescribed open sorcerer in the fact that I wear a stupid hat to conferences. But really, I'm focused on working on open source as pretty much my day job here at Microsoft. So, everything that I do is open source. So, whether it's Internet of Things, reactive programming, scale, or fixing the education system, technical education system, that's what I do. And it's what I love to do.

Wow.

And isn't it 'Vef' Ukraine, not 'L vef'?

I don't know. I have a hard time understanding. 'L-fef', L-fev…

Yeah, 'Vef'.

I don't even know.

Yeah, 'Vef'.

'Vef'. No.

Yeah.

I definitely heard people say the L. But…

Well, it's just because my family's Ukrainian.

And they just say 'Vef'?

Mmhmm, yeah, just V-E-F.

I wonder if everyone's just been humoring me.

Yes. And it used to be part of Poland when it was called Lwów of all things. So, there you go. The more you know. [First] over the rainbow.

[Chuckles].

We need a pronunciation guide.

Exactly.

How is it spelled? Now I really want to know.

L-V-I-V.

Well, it's spelled in Cyrillic but [laughs].

Yeah, L-V-I-V. And when it was Polish, L-W-O-W.

I can't even pronounce the word Cyrillic, let alone read it. I say 'crylic'.

Acrylic writing.

Yeah. Anyway…

So, how about that RxJS? How long have you been at Microsoft?

I want to talk about fixing tech education.

Sure. I can talk about that.

No, we brought you on to talk about Rx, [chuckles] so we better stick to the plan.

I can talk about it more at the end from when we're talking about picks and stuff like that.

Okay.

That's cool. We could talk about functional reactive education, right?

Exactly.

We could always have you back, too.

Yeah. So, I've been at Microsoft for gosh knows, nine years now. And I've been involved with Rx in particular in various forms or fashion since 2009. So, to me it's kind of humorous sometimes, working on the product as long as I have, that it suddenly becomes a mainstream thing five to six years later. For example, we first showed off Rx at JSConf 2010 on Track B and did a whole interview on YouTube and stuff like that. And then sure enough, bam, it becomes a thing. But…

JSConf Track B is where magical things happen, it seems like.

It is.

A lot of cool stuff that's come out of there.

Exactly, it really is. It's just that [inaudible] the things that can't quite be expressed to the conference organizers in one form or fashion. And so, maybe they have poor communication skills. Maybe they just didn't know what they wanted to say or something like that. But suddenly something magical just happens on the stage. And it was that reaction when we showed it. Ryan Dahl, the creator of Node, was there. We had a few other people there as well that were like, “Holy crap. What is this that you just created?”

So, to step back where we began, it was a long story of neat political battles at Microsoft where we were part of the [SQL] organization. And we wanted to find a way to quickly create apps that would work on the web, that would work on the desktop, whether you were targeting Silverlight when that was still a thing, or WPF or plain old JavaScript. The idea was that you could write your script once, hit the compile button, and suddenly JavaScript will pop out and you'll get a nice looking app that looks exactly the same as if you were to compile it to Silverlight and to WPF. That was the intent.

Through various incantations, it went, it struggled because it was really trying to find a niche. People wanted you to do either Silverlight development or web development but there was really no calling at the time for this hybrid approach as it were. So, out of that we got that whole angle of what was called project Volta shut down. But from that we got a number of things that were fairly useful out of it. For example, one of the biggest challenges that we had was, how do we get this notion of first-class events? We had no notion of first-class async as well, because everything in JavaScript was and is in terms of anything I/O related is asynchronous. When you have…

Can you expand a little bit on what you mean by first-class events?

Okay.

Because when I hear that, I think like, “Oh yeah, we've got event listeners in JavaScript.”

Sure, yeah. With first-class events, what I mean is I can create basically, a thing of mouse moves for example, and I could hand you a collection of mouse moves just as I would hand you an array. And then you could start listening to those mouse movements. So, it's different from an event emitter or an event target as you would have in the DOM because all they have basically is 'add event listener' and 'remove event listener'. But the handler itself is what you're really interested in. The handler of sending you data. I want to take that handler and then I want to start filtering it. I want to start composing it with other events. You can't really do that with an event emitter. Instead you have all of this notion of this mouse movement all just wrapped inside this one object. It's all about mouse movements and nothing else.

So, that's really what it's all about when I say first-class, because a callback isn't really a first-class thing as it were. Because you can't really compose callbacks with other callbacks, not particularly very easily. And the same goes for promises. Why promises became a thing is because you didn't really have compositional asynchronous programming there either without you have to resort to things like the async framework, et cetera, or async library, or whatever we call these things, module. So, we didn't even have that at the time. We didn't have promises. We didn't have that. So, we wanted to have something that represented mouse movements or mouse clicks or key ups and key downs, et cetera. And we just couldn't figure out how to quite do it.

So, what we had was we had this idea of, okay we have this thing called link and it's a way of querying data, as it were. And so, why couldn't we apply that also from a pull perspective which was link, to a push perspective which was all about the pushing of these events as they happened. Because it's really just an adaptation of the subject/observer pattern from the Gang of Four. And we just wanted to take that just a little bit further and to make it a really first-class thing that we could do on both sides, whether it's JavaScript and C# at first, and then going to other languages such as C++, Swift, Haskell, PHP, whatever language you want to. It's a pretty universal kind of thing, which is kind of cool, that we came out of that with. But that was our guiding principle, was solving the terrible thing that was async programming.

And we're talking about 2010 here, when we created this. There were no… like I said, promises weren't really a thing. Dojo had their deferred's and jQuery had its own kind of thing with their Ajax stack, but it wasn't really a thing yet. And so, we were kind of the first ones to come out there and say, “Hey, we've got this great idea. But oh, it's closed source, so kind of forget about it.” And then comes 2012, we actually got everything open sourced and all of that. And then it just rapidly expanded from there, once Netflix and others started to adopt it. So, that's the brief history of where we were and how we got to where we are today.

Can you maybe talk about what the practical experience of using these is like compared to something like callbacks or promises?

Sure, absolutely. So, one of the biggest problems that we had was with callbacks, is the fact that you're dealing with these fairly complex for example state machines when you're trying to model some asynchronous behavior. The problem is that what you would do is you would always make your last parameter that callback, and especially with Node, it added the error and then the value that you would get back. The problem with that was, is that you would keep on putting your logic at the next level, at the next level, at the next level. And soon, it would turn into what I'll call a bull's head, or a cow's head in the fact that it would just walk off the screen and then walk back. But there was really no good unified way of dealing with these complex state machines. Everyone calls it callback hell. They've got various names for it.

But it's very hard to linearize your code and just make it look like you're having a coherent thought. Instead you're always thinking about the asynchronous behavior. You're like, “And somehow I hope this global state value is set here. And if it isn't, I'll have to call an error and an error routine goes here.” It becomes very, very disjointed, very quickly when you're trying to build fairly large, complex apps. I'm not just talking about the [inaudible] approach. I'm talking about more complex state logic, whether you're into for example in Netflix's case, launched the movie player which involves authorizing you as a user, logging in, or logging and authorizing you, and I'm getting your list of movies, all of those things being callbacks. There are many error states in between, and how do you model those? And suddenly, your logic gets lost in this sea of callbacks, as it were.

With promises, luckily they tried to fix a lot of that so that you could linearize or think a bit in a single coherent thought. Okay, so I can say, initialize the player, launch the player. Then I can get, authorize the user or log them in. And if it fails, then I send them to unauthorized. Next, I'll get the list of movies. Else, I'll just say you're not allowed to see any movies, you haven't paid, or what have you. So, it builds up this nice little chain where you can chain these previously async operations into a very linear style. So, you can actually follow the business logic as it goes through.

But with observables, we had a different approach there, because what we were trying to solve is not only the single value that promises try to solve for, so for example logging in and so forth, but also dealing with events. Because events could happen zero to infinite number of times. Just your mouse movements to an Ajax request, which could only happen once. So, to solve those under a single banner, and not only that but have various things that we could do along the way such as adding and cancellation and so forth. Things that the promise standard for example doesn't have today is they don't have finally, they don't have cancel, they don't have a lot of these things which we've had since day one, because we were realizing that when we're dealing with evented systems and all of that, we need a way to have it transactional in a way.

That's where observables really plays, is you've got this four quadrant approach where you've got synchronous and asynchronous, single value, multiple value. In that single value asynchronous, obviously you have promises. But observables also work there. But in the multiple value asynchronous, when we're talking about collections, collections of mouse movements, collections of mouse clicks, et cetera, that's where you have observables up there, where your data, when it becomes available, is pushed to you. So, that's putting everything in perspective there.

So, that makes sense. My impression is observables and the RxJS stuff is a lot better if you're working with these collections of things. But would you use the same approach and the same libraries if you're just doing that nested logic style that you were talking about with the promises example where you need to fetch some data and it comes back and then maybe you make another request, maybe you don't?

Yeah, absolutely. Yeah, you can do a lot of those very same things and making it a very straightforward linear style call where I can say do this, then this, then this. Oh by the way, if an exception happens, I have a catch handler here. I have a finally handler that does something here. But then you've got as well is you've got other things such as retry logic. So, I want retry three times or something like that. And if it fails, I return some sort of default logic. So, absolutely. You can model that same kind of approach.

To go back to our Netflix example, we could easily model everything that we talked about with logging in, et cetera, as observables. And with promises, you got a .then to connect things together. And in Rx, you have any number of ways to connect things together. The most common one that you're going to find is flatmap, which the idea there is it seems like a scary name. It's a very academic name for it. But all you have to really think of it is using a map which is basically a thing that we should all know from arrays in JavaScript where you just basically transform each element in the array to something else.

And then merge is basically then in time, as things go along, you just merge them back into a single collection. Because like I said, I'm taking multiple collections and I'm mapping to change their values. And then I want to merge them into a single collection and give it back to you. So, going back to the Netflix example, we could implement all of this with observables today and have a really nice experience. For example, I can say 'player dot initialize dot flatmap, get movies dot retry three times dot catch, return default data'. And the most interesting aspect of it is say, 'take until player doe cancel'. So, someone hits the cancel button, now suddenly the observable sequence stops altogether.

And I don't know quite how to do that in promises. I'm sure you can easily do the same kind of thing. But 'take until' is a very, very useful thing when you're talking about sequences. For example, if you're talking about drag and drop, that you can model as 'mouse down dot flatmap' once again, returning the mouse movement, 'take until mouse up'. So, basically you're just saying mouse down and mouse move, take until mouse up. It's just that kind of linear language that you're talking about here. And so, it's very much the same way here, which is load all the movies, try three times, oh by the way, take until someone hits the cancel button, meaning it's taking far too long or I didn't mean to do that. Does that make sense?

Yeah, that does make sense.

My question was, Rx has been around for a while but the observable spec is now being looked at. So, how much has Rx influenced that?

I would say nearly 100% in terms of the current design. So, the previous design, when Jafar Husain who's been a good friend of Rx since day one and then he left Microsoft to go work at Netflix, so he's been a big advocate of Rx and he's the one who's driven or been the catalyst to drive adoption at Netflix. Now, we saw the standardization of promises for ES2015. And what we saw is necessarily things that we weren't exactly happy with. And the fact that there were things like cancellation was missing, finalization was missing, a lot of those things. But at the same point, we thought that since JavaScript itself, and I'm not talking about the DOM, but the JavaScript language itself does not have an eventing system, because if you're talking about eventing systems, you're talking about something like an event emitter which is basically a subject/observer pattern, or you're talking about an event target, which is basically once again that same kind of pattern. But that isn't core to JavaScript itself.

So, we were like, well why don't we add something to give you first-class events in the core language itself? And so, that led to discussions with Jafar and now Kevin Smith a.k.a. zenparsing on GitHub. And the first way that they try to do it was with async generators, basically turning generators on their head to basically model something where it becomes instead of a pull system with generators when you're calling .next, .next, .next, you're actually feeding the new values calling .next with an actual value. So, let me step back further when I'm talking about subject/observer and so forth. In the case of Rx for example, what I really mean by subject/observer [inaudible] observable and observer, what I mean by that is that you have an observable which is a producer of values. So, it's your mouse movements and so forth. And then you have your observers which are the actual receivers of the logic there. So, that's clarifying just the nomenclature we're using.

That particular proposal about using async generators has since been abandoned. And now what we have is the observable spec that we have right now, or ES observable. And that design is pretty much 100% of what Rx is today in terms of you have your observers, you have your observables, and you have your subscription objects which allow you to encapsulate all of the startup and teardown logic of your particular sequence that you're trying to do. And that's really one key aspect. It's hard to draw in the air on a podcast. But the idea is when you attach an observer to an observable you get back this handle or this subscription. And that subscription knows everything about how you tear down a particular thing. Such as with mouse movements, it knows everything and how to tear down, meaning remove the event listener from the particular event target that you happen to be listening to, whether it's document and so forth.

Once again, promises don't really have this kind of things. So, it's all that codified into one. So, I think it's fairly interesting. And so it's fairly true to Rx implementation as it is right now. And right now it's still in stage one for ES7/2016. But I certainly have hopes that it's going to move forward. And so yeah, the idea there is that you would get basically first-class events. So now, you can talk about in the JavaScript language itself, now you have a way of talking about mouse movements or any such things as a first-class object. So, I can now pass in these collections to you. You can return these collections just like you can with promises for single values.

So, speaking of promises…

Mmhmm.

Tell us about the relationship between observables and promises. It seems like some of the examples on the RxJS GitHub docs actually include promises mixed in with observables somehow.

Absolutely.

Can you tell us, is that encouraged? Is there a use case for that specifically?

Yeah. It is absolutely encouraged for a number of reasons. First reason is there are a lot of APIs out there that use promises naturally. So, why would I want to make someone who wants to be productive in Rx completely abandon the way they're programming right now and just hop on the observable bandwagon? That's just not realistic. Instead, what I want to do is make someone productive as possible using the libraries that they already use.

So for example, we have any number of operators such as concat, flatmap, et cetera that natively just support promises and then convert them into observable sequences under the covers. But it's not really noticeable to you. So, you can pass in for example, you can pass in a promise of an Ajax request. You can pass in a promise of the document loading, whatever it happens to be. And then we'll just treat it just like any other observable value. And what you get out of that is once you don't have to leave the libraries that you're already familiar with, now you can just start mixing it together with events very, very nicely. So, you can get a really nice autocomplete example.

So, like I said, is you can mix events and promises together in an autocomplete scenario because you're mixing in key ups, making sure they're distinct, bouncing it a little bit, all through observables. And then you can call flatmap and call flatmap or flatmap latest which basically makes sure it's only the latest value that should get back with a promise. And then suddenly you've got this magic combination of the two of them together. And not only that, but with ES7/2016, they have this whole notion of async/await. And that's really cool in the fact that you can await promised values and so forth. So, for example any place that we accept promises we now can accept async functions as well. So, you can await certain things in there. So, I can flatmap, say 'flatmap async function data' and then call await on some promise and it just magically works. So, it has so many upsides to just treating it natively like any other piece of data.

Now, as you were describing that, are you talking about the proposed ES7 feature or RxJS as it exists today?

The proposed ES7 feature which is already shipping in show browsers today, for example Microsoft Edge, already has, it's available in some of the latest insider builds right now. And I think Babel and others can precompile it, compile it for you. But yeah, I'm talking about that feature. We do have internally into Rx, we have something that makes observables as those awaitable but using function star and yield and so forth, that you can see in so many other libraries. And we just have supporting observables as last, basically taking the last value, because really with observables you only want one value anyways, in that case.

So, can you talk a little bit about the experience of using this RxJS stuff in some of the common frameworks out there?

Sure.

Are these things that you can just drop in if you're using an Angular app or React app or something like that?

Absolutely. There are just a really huge set of libraries that basically you can use with React today in RxJS. We actually have others at Git Book out there that's linked off of our page. And in there we have a number of things where people are mixing Rx with React, Rx instead of Flux, and so forth. So, there are a lot of really good integration points between the two. For example using subjects which are both observers and observables as your state for React. So, that's for example you can set your state and so forth but instead of having it as just a static object or something like that, but you have it as a subject. That to me is kind of cool.

And for Angular itself, we've shipped Rx.angular for quite a while and that helps deal with any number of things from watches to more of the computed property kind of things to dealing with events and turning them into observables as well as abiding by the safe apply so that you can basically make sure that whenever you're working on something, that it happens during the safe apply. So, all of those things are really good integration points. And there are many, many examples of people using that today. In Angular going forward, they're using Rx at least at the data layer, for example in the HTTP, will now be observables. And you'll basically get a really nice experience.

So, there's a community effort right now to take Rx as it stands today, make it a little bit more performant and a little bit more modular, and just have the community really pitch in and make this a really amazing library. So, I really absolutely encourage that, because I honestly want to see this thing grow. But at the same point, getting those sweet spots for the Angulars, the Reacts, and all the other libraries out there that want to use this as their data layer, as their eventing layer, what have you, we want to give them a really great experience for doing that.

Yeah, that makes sense.

But yeah, like I said, if you look at your Git Book you'll just see just a massive amount of examples of people using React, Angular, and so forth, with Rx natively. So, if you can't find some inspiration then I don't know how to help you. And that really is the key, is if there isn't then just go to our Gitter channel. Chances are you'll find something that works for you.

So, is there a situation where you feel like observables might not be better than callbacks or promises? Are there weaknesses maybe or places where it doesn't work so well?

Well, there are certainly, it might be overkill if you only have one callback or you only have one event kind of thing. If you're really not worried too much and you want to keep your library small, there's really no harm in not using Rx at all, where callbacks do just fine. If all I have is just one little thing to do with the callback, converting that to an observable might be overkill, especially since it's an external library versus something that's completely native. Now, if we're talking native then that's a totally different story.

But there are absolutely trade-offs to make in terms of size of your application and so forth whether you want to make the investment in observables or not. And that pain point that you're going to hit, like I said, is when managing these callbacks just becomes unbearable because all of the state is lying around and you just don't know where the logic is or for things where promises don't quite fit as well, especially when you're dealing with multiple values and so forth. So, if you're talking about events, maybe observables might be a good thing there, especially if you're trying to coordinate multiple events together.

So, as we were talking about frontend frameworks, why would someone use Rx on the backend in place of just plain old Node streams?

Okay. Yeah, Node streams are very good at dealing with binary data. They've been decent at it. I won't say good because they've had their ups and downs with the design process, streams one being an absolute mess when it comes to [inaudible] semantics, back pressure, and so forth, which they tried to fix in streams 2 with the introduction of readable, writable, and transform streams. Then in streams 3, trying to add in these bulk write operations.

Anyway, so that's really good for that. But in terms of handling object [inaudible] data, which they have a capability of doing, it's not super, super great. Because you really only have one mode of talking to one another, and that's basically pipe. So, if I wanted to do a map operation or a filter operation I would have to implement as custom transform stream and then pipe it into that. And if I want to do some filtering or group by's, then I would have to pipe that into a group by stream.

So like I said, it's a very convoluted way of doing things versus I can say 'dot filter' where the values are this, and I can group by these particular values. And then I can do some other things such as buffering and mapping and merging, et cetera, that Node streams just aren't very good at. They're very good at straight-ahead I/O. Okay. So, I've got an HTTP server, I want to send some data in. I want to mux it through a pipe and I want to demux it on the other side. Great. Node streams are really good at that. But if you're talking about stock ticker data, you're talking about WebSocket data, you're talking about any sort of data stream in terms of being raw data, it really helps you to think about it with observables. Because now you have this relational algebra that you could use with it such as your maps, your filters, your reduces, your group by's, and so forth, that allow you to really time-slice data really nicely.

And we do have an example of that in our examples. And I definitely need to add more of them. But it was taking stock ticker data d starting to analyze them by ticket symbol and then time-slicing it by five days to see whether there have been 10% increases or decreases over time. So, all of that is really, really valuable in terms of what you would do on the server. Because when we're talking about Node, we're usually talking about data transfer, data processing, and so forth. And Rx streams as it were, is really, really good at that.

I'd be interested in looking at that with something like RabbitMQ.

Absolutely, yeah. That's the way that I had approached it earlier, is doing that, is basically taking in this data then starting to time-slice it, starting to do some group by's and so forth by symbol, et cetera. So yeah, absolutely.

Basically I wanted to get your opinion on the future. Are promises dying? And should we all run and hide, because the sky is falling?

No. I don't think promises should die. Do I think they should be fixed in its current incantation? Absolutely, yes. There are certainly a lot of very low bar things that they could have done and that they should have done such as adding the finally case so that when you're dealing with anything I/O related, that you can actually tear it down afterwards and be sure that nobody's going to come in afterwards and do a 'then' on you again and suddenly now you've entered in a weird state. So, that certainly needs to be fixed. The cancellation, it's maybe a 20% case that people use it for. So, having an additional, say a subclass for a cancellable promise can be done today and hopefully will be. I don't know if there's a standard proposal out there for it yet. But I know that there's certainly been discussion around it to fix those issues.

There are other things obviously that some people don't like about promises in the fact that promises will swallow errors whether you like it or not, and then basically you have to catch them on the next 'then-able' instead of actually getting that error thrown to you. And there are other things such as the forced async model. So, it's always going to be async whether you wanted it to be or not. Whereas callbacks could be perfectly synchronous. And now you've just added on this overhead of even as minimal as it may be with this next tick or micro-task kind of thing, it's still, in the fact that you took up an extra tick that you might not have wanted.

I don't want to ask you to speak for others, but there is this sentiment out there that we should stop using promises, expressed by people. I've heard it from Netflix and stuff. Even if promises fix some of these, let's call them shortcomings…

Mmhmm?

Would you still be a proponent of observables over promises generally or not?

Generally, yes. And the reason why is because t unifies, would say all four quadrants of that reactive programming quadrant that I was talking about earlier in the fact that you can take anything and turn it into an observable. So, whether it's an event, whether it's as callback, a multivalue thing such as an array, set, map, et cetera, or just single value, you have adapters for pretty much everything. And then you could treat it as a single programmatic model. And the reason why that's interesting for a lot of people, for example if you're creating and using a stack such as Vert.x or what have you and you're using RxJava on the backend, now you're suddenly, okay, I

understand observables. This is great. I'm doing server-side programming. It's observables. This is great. Now I get transferred to the frontend. Oh by the way, now you're dealing with observables again. Oh, I understand observables.

So, suddenly your skills as a developer are immediately transferable from one thing to the other. They do not diverge in terms of meaning and so forth, versus Java promises versus JavaScript promises are different and act different. So, if you had this basically, I would call it more along the lines of, you might be speaking in different programming languages but you still speak the same domain language, as it were. And that's certainly one advantage you just can't get in many other places. And not only that, but like I said, is you get the advantages with deterministic tear-down of events, good error-handling, retry logic, basically the whole kitchen sink, as it were, if you really want it.

So, what are areas that you see people get hung up or stuck when they're new to observables?

What are some of the gotchas that can come up?

Sure. Yeah, the first thing that people get stuck with for example is they think that things start to fire immediately. For example, when they're doing a scan operation which is an incremental reduce operation, they think that oh, the values will just start to flow immediately. It's not quite that way. Observables are lazy, so therefore they're not going to start emitting anything until you call subscribe. And then usually, you have to call 'start with' to actually give it a real value. It's kind of annoying, but it is what it is with Rx.teardown

The other aspects seem to be, I want to share the same data stream with someone else. By the fact of Rx streams being immutable by default, meaning if I hand you a thing of mouse movements, when you call subscribe you get a whole new collection of mouse moves. You don't get the same collection that I do. People then go, oh no, no, no. I want the same one. Well, that's when you get into this whole connectible stuff that I'd rather not get into. But it's the, people get hung up on the sharing aspects of streams.

Another part is this whole notion of hot versus cold observables. And the easiest way to describe that is a hot observable is well, I'm going to go see a play. So, a play could have different actors on a different day. And more or less it's the same story, but there could be variations on a different day. And that's perfectly analogous to mouse movements, mouse clicks, et cetera. It's not a constant thing. And when you start listening to it, it's basically when you start getting data.

Now compare and contrast that to what we'll call cold observables. This is like a movie. So, a movie and the very fact of, I can go and I can, oh, I started in the middle of it? Oh, I'm going to go back to the beginning and catch up from the beginning and I'm going to replay the whole thing for you. So, any time you take an array, you take a set, you take a generator, et cetera, I'm going to produce you the same value time and time and time again. Whereas like I said, in mouse movements, it just doesn't make sense to start recording mouse movements from the beginning of time. But with arrays and so forth, you want that kind of assurance that you get all of those values that you expect to be in that collection. And people sometimes get hung up on that hot versus cold thing.

And some people, who have implemented some form of Rx such as ReactiveCocoa, have made a distinct separation between the two of those what people will call very different terms. And functional reactive programming itself has also made that very distinction very well-known, which is the difference between a behavior, a thing with a constant value, and a signal or event, a discrete event. So, that's really some of the hang-ups that people get caught up on.

Sure.

But then again, I'm deep in the weeds, so I…

Well no, that's a good sign that you know what some of the hang-ups are.

Yeah.

Because it means that… Any technology has downsides. Any technology has things that are tricky for people to get into it at first. And I always get a little scared when it's like, “What's hard about this?” and someone's like, “Nothing. It's perfect.”

Yeah, yeah.

That's when you worry that they're not telling you something. I'll tell you upfront…

Yeah.

That there is a learning curve, absolutely. I will grant anyone that there is a learning curve. But as soon as you start breaking down this idea, saying that this mouse is basically a database that I can query just as much as I can query MongoDB or whatever I want to query, then it becomes a lot easier. Because you're thinking in maps and filters and so forth. You're like, “Oh, I can apply the same thing to arrays. Now I can apply it to mouse movements. But I get this extra added bonus of this time element to it.” And that's the easiest way I've found to explain it to people, is now you've got this collection over time that you can query.

Yeah. Have you seen these ideas influence other technologies or frameworks that have come out or become popular since then?

Certainly there are a lot of frameworks that try but basically are influenced by Rx certainly out there. And I would certainly say that React has taken a lot of ideas and looked at it for ideas for Flux and for React itself. So, it's certainly been some influence there. Where it's been a lot of influence I would say is in the Dart programming language for example. If you take a look at their async stack, it's basically Rx all over again. So, anything there which is a neat thing is they took the I/O nature of streams and events such as movements and combined it into one thing. So, now you could treat mouse movements and a stream of data as the same thing. You get the same maps and filters, et cetera. And the world's a happy place.

Unfortunately, Node didn't go that way. And then there's a W3C Streams proposal which is also pretty much following a lot of what Node streams did but adding promises on top of it. They could have done a better job of saying, “I'm going to take something like observable and look at that as a basis for that,” instead of something that's super fairly low-level, I/O related. Something that you could really, really reuse for a lot of things.

What about stuff like, have you looked at Elm at all? I know they build…

Oh yeah.

FRP into the core of the language.

Yeah. Yeah, so with Elm, it's pretty much a language that kind of looks like Haskell. And what they call it is FRP, [inaudible] FRP. And I'd rather not get down into the weeds of whether it is or is not FRP. I'll [inaudible] that to Conal Elliott who created FRP. Because quite honestly, it's a very much religious battle about the whole…

Really?

About the whole term, absolutely, in that Conal Elliot's and the late Paul Hudak created this term about 1998. And it was primarily to deal with continuous time versus discrete time. So, a lot of systems, especially distributed, were talking about using discrete time. And in the world of events and so forth, that's when you're talking about discrete time. But when you're talking about something like a clock and so forth, that always has a value and it's dealing with continuous time.

So, think of your clock as something that always has a value and continues over time. And then you've got this separation of discrete events, what we'll call as something like a mouse click. Well, a mouse click doesn't always have a value right now. So, that's kind of a discrete thing. So, what [he] was talking about, really [he] was talking about the idea of having this algebra as it were, to combine these two into a single thing, call it functional reactive programming. There's a much more grandiose title that he came up with but the easiest thing at the time back in 1998 when this was created was FRP. And what he created was a language called Fran which was a few Win32 executables. I don't know if they still run on Windows at all. But it was a very interesting experiment. And from there, there's been some follow on research and so forth.

So, throughout Rx history, we've definitely said that we respect the founding of FRP and we know that we for example do not deal with continuous time as it would be pretty much impossible to model that in JavaScript itself. You just really can't do that, because you're dealing with ticks, next ticks, and callbacks and so forth. But what you're supposed to be doing is dealing with those things as if there weren't any callbacks at all. So, X would just magically change on its own without any callbacks or anything.

So, taking that to Elm, so Elm leaves off that notion of continuous time. So, there's been that controversy as it were, as to whether that's FRP or not. And I will, like I said, I'll leave that judgment to the founder of FRP. But like I said, I won't advertise Rx as FRP, because it's not. It's only dealing with discrete events. And Elm also follows the same way, is they’re dealing with signals which are discrete events. But what's really neat about that language is it really distills down to these firstclass events in such a way that you can do some really, really neat things. Especially with their replay logic where you can go forwards and backwards in time, which I think is really, really cool and allows for some really nice game programming, some really nice frontend. Because it's really easy to model things such as gravity and so forth.

We took one of those examples with using Rx and we took the Elm example of using Mario and then basically transported into Rx. So, it's not as beautiful obviously. You're dealing with a lot more semicolons, curly braces, and so forth, than the Elm example. So, if you're really comfortable with the Haskell, Elm is a wonderful language. And it's a neat thing to be able to prototype new UIs using it. And it's really fast as well, which is another great thing. Would I like to see something like React and something like that with it, kind of more declarative UIs in terms of mixing and matching HTML with Elm? Absolutely, versus more declarative UIs that you're talking about directly in the code. Either way, it's still a very cool language.

So, the thing I got from that is developers will fight to the death over any arbitrary distinction.

Oh, absolutely, absolutely.

FRP, not FRP, tabs versus spaces, semicolons, no semicolons.

Oh, absolutely. But yeah…

And it doesn't matter how many academic papers you read. You just fight about things that have more complicated names.

Oh, exactly. Could FRP have chosen a different name that was a little bit more descriptive? Sure. This is 1998 we're talking about, the birth still of the internet, and desktop apps and so forth. And so, it was a term chosen way back when. Quite honestly, I'd like to honor his original intents. And I'm like, “Well, I don't fall into that so I'm not going to call my stuff that, in fact.”

Sure.

So yeah, we will disagree about certain things. But at least in terms of his intent of the paper versus what people call their particular things, don't always match. And so, that's where you're going to have to quibble in the semantics of whether someone is right or wrong.

That makes sense.

We've been talking about observables and Rx interchangeably. Are observables in ES 2016? I think that's right.

Mmhmm.

Are they going to replace Rx?

As a base, probably, yes. That would probably be a thing. And then you would basically have Rx as an add-on layer, as it were. So, we would add on all of the operators or all of the things like map, filter, et cetera, that aren't in the standard itself. So, basically you're building this nice facade on this bare object, as it were. And so yeah, absolutely. Rx would easily come in and fix some of those things. And not only that, but add in things like the concurrency layer via the schedulers that we have as the core part of Rx that we don't really talk about.

And that is probably one of the more interesting aspects, which allows for us to do virtual timetesting so that I can for example say that this event happened at this particular time, this transformation happened at this particular time, and this particular filtering operation happened at this particular time. And then I can run it a thousand times and I will always get the same answer. That's a great thing that we built in. So, instead of having continuous time which we talked about as being part of FRP, we have this notion of virtual time so that you could literally swap out your concurrency layer at any point in computation.

So for example, one really useful thing to do would be for example if I am doing some sort of animation. Now animations, you really only want to do via request animation frame. So, to get a nice transition, make sure you're not overly beating up on your machine. Well, in RxJS DOM, we have request animation frame scheduler. So, you can basically say, “Okay, I'm going to do some drawing. And then I want to use the request animation frame scheduler to basically schedule all the work using request animation frame.” And it just goes and does it there. Otherwise, we can use any number of things such as if we had something like, “I want a schedule a mutation observer which goes really fast. I want to use set immediate, I want to use process next tick, I want to use set timeout.”

Whatever that mechanism happens to be, we can use via schedulers. And that's one of the really cool parts about dealing with this particular thing, is this underlying scheduler has so much control about how, where, and when things happen. So, adding those things into the spec I think would be super, super useful. Or on top of it, rather.

It doesn't sound like there are any other questions. So, let's go ahead and do some picks.

Before we get to the picks I just want to acknowledge our silver sponsors.

Aimee, do you want to start us with picks?

Sure. So, my first pick was going to be something I saw this week that probably was all over Twitter. But it's a cartoon guide to Flux. And so, I'm a pretty visual learner and I enjoyed looking at that.

The second pick again is like a visual thing. It's a promise visualizer. So again, because I'm visual, that was really, really helpful. So, those are my two picks for this week.

Alright. Jamison, what are your picks?

I also have two picks. The first one is an album by my favorite band. I think they've finally taken over the top spot. It's 'Act IV Rebirth in Reprise' by The Dear Hunter. They make these epic melodic prog rock albums and they're all concept albums about this continuous story of this kid's life. I think they're up to about World War II now. It starts off in the late, maybe the early 20th century, late 19th century. And then it just follows him and all the stuff that happens in his life. I wouldn't care about that, except the music is actually really good. And so, it just adds another layer onto it. So, I've been listening to that non-stop. And it's amazing.

My next pick is a talk by, I forgot her real name. I only have her Twitter handler, jessiechar. I think she's an iOS developer. But it's called 'Expert on Nothing' and it's about a few different things. But one of the things I really liked is she talks about the plague of thought leader-ism and the need to appear like you're certain about everything and to avoid ambivalence and nuance in order to say these strong, powerful statements that attract people to your ideas. And how that's not really how the world works. And there's value in recognizing two sides. Not being apathetic between the two but recognizing that the trade-offs make things more complicated than just, “This is always better.” Except for RxJS. Sorry. This isn't… [Laughs]

Yeah, yeah, yeah. I was like, “You're wrong.”

That's obviously a terrible [inaudible].

Yeah.

[Inaudible] Rx for everything, duh.

There are some things that [inaudible]…

Better. But there are also some things that only you just sound cool if you say they're better. And I really like that about her talk. So, those are my picks.

[Inaudible] future marketing.

Sorry.

Alright. Well Dave, what are your picks?

Yeah, sorry. I cut you off, Jamison.

[Inaudible] because you're so quiet. So, I just [inaudible] over you.

Alright. I have two picks today. One is a nifty feature that I rediscovered and re-enjoyed this week in the Chrome Developer Tools which is the feature called XHR Breakpoints. This is where you can add a breakpoint so that any time your JavaScript code issues an Ajax request, you can cause a breakpoint to happen. And you can filter it so that only certain Ajax requests will actually trigger the breakpoint. That in conjunction with the magical async check box which I think might be checked by default, lets you reconstruct, find the code that actually initiated that Ajax request, which is super handy.

The second one is a YouTube channel with some 'internetertainers' called, a little show called 'Glove and Boots' which is a few puppets that do some funny stuff. And some of them are pretty darn hilarious. So, those are my picks.

Alright. Joe, do you have some picks for us?

You bet. Absolutely. So, I want to pick programming. One, because I think programming is pretty cool. But mostly because programming is a really awesome discipline because unlike many other disciplines, programming is one of those things where a guy in his garage can make an amazingly significant change on the world. And so, case in point would be the Elm programming language. Evan's doing his undergraduate thesis at school and essentially all by himself invents this really awesome language. And it is having a very positive effect on the industry. And it's just one example of a gazillion examples you could come up with which is why I think programming is awesome.

So…

In the case of Elm, it wasn't a garage. I think it was history class, right?

[Chuckles] Yeah. A guy in history class. [Laughs] Bored to tears with whatever the current subject was and said, “I'm going to write a thesis on something crazy.” And so, because of that my second pick is going to be Evan's thesis for Elm. I've actually been reading it. And like all theses, it's not exactly light reading. But it is very interesting. And I find it to be digestible, certainly, just with a little bit of thought. And what our guest was talking about today about RxJS and the history of it, and the guys that invented it, and then this continuous time thing, he actually talks about and explains a lot of that in his thesis. So, I'm going to pick Evan's thesis, his thesis on Elm, which you can easily find online by googling. And we'll put a link to it in the show notes. And that will be my second pick.

Alright. I'm going to hop in and pick a book. It's called 'The Alchemist'. It's by Paulo Coelho. I'm sure I said that wrong. But it's one of those allegorical books, like if you've read 'The Richest Man in Babylon' or I've read a couple of others that I'm trying to remember names of. But anyway, so it's a story of this young man who travels to find his treasure. And it's all about your life's calling and things like that. And anyway, it's really, really fascinating. And I really enjoy it. Or I've enjoyed it so far. I'm about a quarter of the way through it. I'm actually listening to it on Audible. And it's read by Jeremy Irons who if you're not familiar with him, he's been in a ton of movies. He was the voice of Scar in 'The Lion King'. He just has this awesome, rich, wonderful narration voice for this book. And so, I have to pick the Audible version because it is really good. And yeah, that's my pick this week.

Oh, I'm also going to pick the Ionic framework. I've been playing with that and I've been enjoying that as well. Matt, what are your picks?

Okay. Well, if I were going to pick a Jeremy Irons thing, let's see. I would probably have him read me the phone book or something like that, because it would probably sound just as profound. Him or Alan Rickman or James Earl Jones or Morgan Freeman, probably. I think that would be pretty slick.

So anyway, my choices here. The first one would be the Thali Project which is one of my other main projects that I work on. And that's, the idea is basically recreating the peer web. And so, that you on your iOS and Android devices and just about anything else can share files peer-to-peer with one another without any centralized authority as it were. So, you and I can share photos. We can share pictures, music, whatever. And it just synchronizes via Bluetooth or Wi-Fi direct, based upon the platform that we're working on. And this has a number of implications anywhere from IoT in factories to enabling people to communicate in poor areas, to saving someone's life on a battlefield kind of thing. So, that's one of my big bets coming up.

The other one is of course changing technology education as we know it today. And that is through the BBC Micro Bit. And that is a really cool little chipset that kids can program very, very easily. And it comes with where you can use seven different jumper cables to make it do various things. But it also has a display that you can program as well. So, I think it will dramatically change how we're doing technical education in the next five years. I think it's just incredible.

And since everyone seems to be doing a music pick, let's see. What should I pick out of the hat? Well, let's see. There's the Minutemen which is always a good listen, even though it was a band back from the early 1980s, a post-punk band. But it's always still to this day held a pretty close place in my heart. So, that's it for me.

Alright. Well, thank you for coming and thanks for sharing. And thanks for all of your work on RxJS.

Thank you.

Yeah, thank you. This was great.

Alright. Well, we will wrap this show up and we'll catch everyone next week.