091: RxJS with Ben Lesh and Tracy Lee

Tracy Lee: @ladyleet | ladyleet.com

Ben Lesh: @benlesh | medium.com/@benlesh

Show Notes:

• 00:50 - What is This Dot?
• 03:26 - The RxJS 5.5.4 Release and Characterizing RxJS
• 05:14 - Observable
• 07:06 - Operators
• 09:52 - Learning RxJS
• 11:10 - Making RxJS Functional Programming Friendly
• 12:52 - Lettable Operators
• 15:14 - Pipeline Operators
• 21:33 - The Concept of Mappable
• 23:58 - Struggles While Learning RxJS
• 33:09 - Documentation
• 36:52 - Surprising Uses of Observables
• 40:27 - Weird Uses of RxJS
• 45:25 - Announcements: WHATWG to Include Observables and RxJS 6

Resources:

• this.media
• RxJS
• RX Workshop
• Ben Lesh: Hot vs Cold Observables
• learnrxjs.io
• RxMarbles
• Jewelbots

Transcript:

CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 91. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. Joining me today on the podcast is Elrick Ryan. Hello, Elrick.

ELRICK: Hey, what’s up?

CHARLES: Not much. How are you doing?

ELRICK: I’m great. Very excited to have these two folks on the podcast today. I feel like I know them…

CHARLES: [Laughs]

ELRICK: Very well, from Twitter.

CHARLES: I feel like I know them well from Twitter, too.

ELRICK: [Laughs]

CHARLES: But I also feel like this is a fantastic company that is doing a lot of great stuff.

ELRICK: Yup.

CHARLES: Also not in Twitter. It should be pointed out. We have with us Tracy Lee and Ben Lesh from This Dot company.

TRACY: Hey.

CHARLES: So first of all, why don’t we start, for those who don’t know, what exactly is This Dot? What is it that you all do and what are you hoping to accomplish?

TRACY: This Dot was created about a year ago. And it was founded by myself and Taras who work on it full-time. And we have amazing people like Ben, who’s also one of our co-founders, and really amazing mentors. A lot of our friends, when they refer to what we actually do, they like to call it celebrity consulting.

[Laughter]

TRACY: Which I think is hilarious. But it’s basically core contributors of different frameworks and libraries who work with us and lend their time to mentor and consult with different companies. So, I think the beautiful part about what we’re trying to do is bring together the web. And we sort of do that as well not only through consulting and trying to help people succeed, but also through This Dot Media where it’s basically a big playground of JavaScripting all the things. Ben and I do Modern Web podcast together. We do RX Workshop which is RxJS training together. And Ben also has a full-time job at Google.

CHARLES: What do they got you doing over there at Google?

BEN: Well, I work on a project called Alkali which is an internal platform as a service built on top of Angular. That’s my day job.

CHARLES: So, you’ve been actually involved in all the major front-end frameworks, right, at some point?

BEN: Yeah, yes. I got my start with Angular 1 or AngularJS now, when I was working as a web developer in Pittsburgh, Pennsylvania at a company called Aesynt which was formerly McKesson Automation. And then I was noticed by Netflix who was starting to do some Angular 1 work and they hired me to come help them. And then they decided to do Ember which is fine. And I worked on a large Ember app there. Then I worked on a couple of large React apps at Netflix. And now I’m at Google building Angular apps.

CHARLES: Alright.

BEN: Which is Angular 5 now, I believe.

CHARLES: So, you’ve come the full circle.

BEN: Yeah. Yeah, definitely.

CHARLES: [Chuckles] I have to imagine Angular’s changed a lot since you were working on it the first time.

BEN: Yeah. It was completely rewritten.

TRACY: I feel like Angular’s the new Ember.

CHARLES: Angular is the new Ember?

TRACY: [Laughs]

BEN: You think?

TRACY: Angular is the new Ember and Vue is the new AngularJS, is basically. [Laughs]

CHARLES: Okay.

[Laughter]

CHARLES: What’s the new React then?

BEN: Preact would be the React.

CHARLES: Preact? Okay, or is Glimmer…

BEN: [Laughs] I’m just…

CHARLES: Is Glimmer the new React?

BEN: Oh, sure. [Laughs]

CHARLES: It’s important to keep these things straight in your head.

BEN: Yeah, yeah.

CHARLES: Saves on confusion.

TRACY: Which came first?

[Chuckles]

BEN: Too late. I’m already confused.

CHARLES: So now, before the show you were saying that you had just, literally just released RxJS, was it 5.5.4?

BEN: That’s right. That’s right. The patch release, yeah.

CHARLES: Okay. Am I also correct in understanding that RxJS has kind of come to very front and center position in Angular? Like they’ve built large portions of framework around it?

BEN: Yeah, it’s the only dependency for Angular. It is being used in a lot of official space for Angular. For example, Angular Material’s Data Table uses observables which are coming from RxJS. They’ve got reactive forms. The router makes use of Observable. So, the integration started kind of small which HTTPClient being written around Observable. And it’s grown from there as people seem to be grabbing on and enjoying more the React programming side of things. So, it’s definitely the one framework that’s really embraced reactive programming outside of say, Cycle.js or something like that.

CHARLES: Mmhmm. So, just to give a general background, how would you characterize RxJS?

BEN: It’s a library built around Observable. And Observable is a push-based primitive that gives you sets of events, really.

CHARLES: Mmhmm.

BEN: So, that’s like Lodash for events would be a good way to put it. You can take anything that you can get pushed at you, which is pretty much value type you can imagine, and wrap it in an observable and have it pushed out of the observable. And from there, you have a set of things that you can combine. And you can concatenate them, you can filter them, you can transform them, you can combine them with other sets, and so on. So, you’ve got this ability to query and manipulate in a declarative way, events.

CHARLES: Now, Observable is also… So, when Jay was on the podcast we were talking about Redux observable. But there was outside of the context of RxJS, it was just observables were this standalone entity. But I understand that they actually came from the RxJS project. That was the progenitor of observables even though there’s talk of maybe making them part of the JavaScript spec.

BEN: Yeah, that’s right. That’s right. So, RxJS as it stands is a reference implementation for what could land in JavaScript or what could even land in the DOM as far as an observable type. Observable itself is very primitive but RxJS has a lot of operators and optimizations and things written around Observable. That’s the entire purpose of the library.

CHARLES: Mmhmm. So, what kind of value-adds does it provide on top of Observable? If Observable was the primitive, what are the combinators, so to speak?

BEN: Oh, right. So, similar to what Lodash would add on top of say, an iterable or arrays, you would have the same sorts of things and more inside of RxJS. So, you’ve got zip which you would maybe have seen in Lodash or different means of combines. Of course, map and ‘merge map’ which is like a flattening sort of operation. You can concatenate them together. But you also have these time-based things. You can do debouncing or throttling of events as they’re coming over in observable and you create a new observable of that. So, the value-add is the ability to compose these primitive actions. You can take on an observable and make a new observable. We call it operators. And you can use those operators to build pretty much anything you can imagine as far as an app would go.

CHARLES: So, do you find that most of the time all of the operators are contained right there inside RxJS? Or if you’re going to be doing reactive programming, one of your tasks is going to be defining your own operators?

BEN: No, pretty much everything you’d need will be defined within RxJS. There’s 60 operators or so.

CHARLES: Whoa, that’s a lot.

BEN: It’s unlikely that someone’s going to come up with one. And in fact, I would say the majority of those, probably 75% of those, you can create from the other 25%. So, some of the much more primitive operators could be used…

TRACY: Which is sort of what Ben did in this last release, RxJS 5…. I don’t know remember when you introduced the lettable operators but you…

BEN: Yeah, 5.5.

TRACY: Implemented [inaudible] operators.

BEN: Yeah, so a good portion of them I started implementing in terms of other operators.

CHARLES: Right. So, what was that? I didn’t quite catch that, Tracy. You said that, what was the operator that was introduced?

TRACY: So, in one of the latest releases of RxJS, one of the more significant releases where pipeable operators were introduced, what Ben did was he went ahead and implemented a lot of operators that were currently in the library in terms of other operators, which was able to give way to reduce the size of the library from, I think it was what, 30KB bundled, gzipped, and minified, to about 30KB, which was about 60 to 70% of the operators. Right, Ben?

BEN: Yeah. So, the size reduction was in part that there’s a lot of factors that went into the size reduction. It would be kind of hard to pin it down to a specific operator. But I know that some of the operators like the individual operators themselves, by reimplementing reduce which is the same as doing as scan and then take last, implementing it in terms of that is going to reduce the size of it probably 90% of that one particular file. So, there’s a variety of things like that that have already started and that we’re going to continue to do. We didn’t do it with every operator that we could have. Some operators are very, very common and consequently we want them to be as optimized as possible. For example, map. You can implement map in terms of ‘merge map’ but it would be very slow to do so. It might be smaller but it would be slower. We don’t want that. So, there are certain areas we’re always going to try to keep fairly a hot path to optimize them as much as possible. But in other spots like reduce which is less common and isn’t usually considered to be a performance bottleneck, we can cut some corners. Or ‘to array’ or other things like that.

CHARLES: Mmhmm.

TRACY: And I think another really interesting thing is a lot of people when learning RxJS, they… it’s funny because we just gave an RX Workshop course this past weekend and the people that were there just were like, “Oh, we’ve heard of RxJS. We think it’s a cool new thing. We have no plans to implement it in real life but let’s just play around with it and let me learn it.” I think as people are starting to learn RxJS, one of the things that gets them really overwhelmed is this whole idea that they’re having to learn a completely new language on top of JavaScript or what operators to use. And one of our friends, Brian Troncone who is on the Learning Team, the RxJS Learning Team, he pulled up the top 15 operators that were most commonly searched on his site. And some of them were ‘switch map’, ‘merge map’, ‘fork join’, merge, et cetera. So, you can sort of tell that even though the library has quite a few… it’s funny because Ben, I think the last RX Workshop you were using pairs and you had never used it before.

BEN: Yeah.

TRACY: So, it’s always amusing for me how many people can be on the core team but have never implemented RxJS…

CHARLES: [Laughs]

TRACY: A certain way.

BEN: Right. Right, right, right.

CHARLES: You had said one of the recent releases was about making it more friendly for functional programming. Is that a subject that we can explore? Because using observables is already pretty FP-like.

BEN: What it was before is we had dot chaining. So, you would do ‘dot map’ and then call a method and then you get an observable back. And then you’d say ‘dot merge’ and then you’d call a method on that, and so on and so forth. Now what you have is kind of a Ramda JS style pipe function that just takes a comma-separated list of other functions that are going to act upon the observable. So, it reads pretty much the same with a little more ceremony around it I guess. But the upside is that you can develop your operators as just higher-order functions.

CHARLES: Right. And you don’t have to do any monkey-patching of prototypes.

BEN: Exactly, exactly.

CHARLES: Because actually, okay, I see. This is actually pretty exciting, I think. Because we actually ran into this problem when we were using Redux Observable where we wanted to use some operators that were used by some library but we had to basically make a pull request upstream, or fork the upstream library to include the operators so that we could use them in our application. It was really weird.

BEN: Yeah.

CHARLES: The reason was because it was extending the observable prototype.

BEN: Yeah. And there’s so many… and that’s one way to add that, is you extend the observable prototype and then you override lift so you return the same type of observable everywhere. And there are so many things that lettable operators solved for us. For example…

CHARLES: So, lettable operators. So, that’s the word that Tracy used and you just used it. What are lettable operators?

BEN: Well, I’ve been trying to say pipeable and get that going instead of lettable. But basically there’s an operator on RxJS that’s been there forever called let. And let is an operator and what you do is you give it a function. And the function gives you the source observable and you’re expected to return a new observable. And the idea is that you can then write a function elsewhere that you can then compose in as though it were an operator, anywhere you want, along with your other dot-chained operators. And the realization I had a few months ago was, “Well, why don’t we just make all operators like this?” And then we can use functional programming to compose them with like a reduce or whatever. And that’s exactly what the lettable operators are. And that’s why I started calling them lettable operators. And I kind of regret it now, because so many people are saying it and it confuses new people. Because what in the world does lettable even mean?

CHARLES: Right. [Laughs]

BEN: So, they are pipeable operators or functional operators. But the point is that you have a higher-order function that returns a function of a specific shape. And that function shape is, it’s a function that receives an observable and returns an observable, and that’s it. So, basically it’s a function that transforms an observable into a new observable. That’s all an operator. That’s all an operator’s ever been. It’s just this is in a different flavor.

CHARLES: Now, I’m curious. Why does it do an observable into an observable and not a stream item into an observable? Because when you’re actually chaining these things together, like with a map or with a ‘flat map’ or all these things, you’re actually getting an individual item and then returning an observable. Well, I guess in this case of a map you’re getting an item and returning an item. But like…

BEN: Right, but that’s not what the entire operation is. So, you’ve got an operation you’re performing whenever you say, if you’re to just even dot-chain it, you’d say ‘observable dot map’. And when you say ‘dot map’, it returns a new observable. And then you say ‘dot filter’ and it returns another new observable.

CHARLES: Oh, gotcha, gotcha, gotcha. Okay, yeah, yeah, yeah. Yeah, yeah.

BEN: So, this function just embodies that step.

CHARLES: I see, I see. And isn’t there some special… I feel like there’s some proposal for some special JavaScript syntax to make this type of chaining?

BEN: Yeah, yeah, the pipeline operator.

CHARLES: Okay.

BEN: I don’t know. I think that’s still at stage one. I don’t know that it’s got a lot of headway. My sources and friends that are in the TC39 seem to think that it doesn’t have a lot of headway. But I really think it’s important. Because if you look at… the problem is we’re using a language where the most common use case is you have to build it, get the size as small as possible because you need to send it over the wire to the browser. And understandably, browsers don’t want to implement every possible method they could on say, Array, right?

CHARLES: Mmhmm, right.

BEN: There’s a proposal in for ‘flat map’. They could add zip to Array. They could add all sorts of interesting things to Array just by itself. And that’s why Lodash exists, right?

CHARLES: Right.

BEN: Is because not everything is on Array. And then so, the onus is then put on the community to come up with these solutions and the community has to build libraries that have these constraints in size. And what stinks about that is then you have say, an older version of Lodash where you’d be like, “Okay, well it has 36 different functions in it and I’m only using 3 of them. And I have to ship them all to the browser.”

CHARLES: Mmhmm.

BEN: And that’s not what you want. So, then we have these other solutions around tree-shaking and this and that. And the real thing is what you want is you want to be able to compose things left to right and you want to be able to have these functions that you can use on a particular type in an ad hoc way. And there’s been two proposals to try to address this. One was the ‘function bind’ operator,

CHARLES: Mmhmm.

BEN: Which is colon colon. And what that did is it said, “You can use this function as a method, as though it were a method on an object. And we’ll make sure that the ‘this’ inside that function comes from the instance that’s on the left-hand side of colon colon.”

CHARLES: Right.

BEN: That had a bunch of other problems. Like there’s some real debate I guess on how they would tie that down to a specific type. So, that kind of fell dead in the water even though it had made some traction. And then the pipeline operator is different. And then what it says is, “Okay, whatever is on the…” And what it looks like is a pipe and a greater than right next to each other. And whatever’s on the left-hand side of that operand gets passed as the first argument to the function on the right-hand side of that operand.

CHARLES: Mmhmm.

BEN: And so, what that means is for the pipeable operators, instead of having to use a pipe method on observable, you can just say, “instance of observable, pipeline operator and an operator, and then pipeline operator, and then the Rx operator, and then pipeline operator and the Rx operator, and so on.” And it would just be built-in. And the reason I think that JavaScript really needs it is that means that libraries like Lodash can be written in terms of simple functions and shipped piece-meal to the browser exactly as you need them. And people would just use the pipeline operator to use them, instead of having to wrap something in a big object so you can dot-chain things together or come up with your own functional pipe thing like RxJS had to.

CHARLES: Right. Because it seems it happens again and again, right? Lodash, RxJS, jQuery. You just see this pattern of chaining, which is, you know…

BEN: Yeah, yeah. People want chaining. People want left to right composition.

CHARLES: Mmhmm.

BEN: And it’s problematic in a world where you want to shake off as much unused garbage as possible. And the only way to get dot chaining is by augmenting a prototype. There’s all sorts of weird problems that can come with that. And so, the functional programming approach is one method. But then people look at it and they say, “Ooh, yuck. I’ve got to wrap things in a function named pipe. Wouldn’t it be nicer if there was just some syntax to do this?” And yeah, it would be nicer. But I have less control over that.

CHARLES: Right. But the other alternative is to have right to left function composition.

BEN: Right, yeah.

CHARLES: But there’s not any special syntax for that, either.

BEN: Not very readable.

CHARLES: Yeah.

BEN: So, you just wrap everything. And the innermost call is the first one and then you wrap it in another function and you wrap that in another function, and so on. Yeah, that’s not [inaudible]. But I will say that the pipe function itself is pretty simple. It’s basically a function that takes a rest of arguments that are all functions.

CHARLES: Mmhmm.

BEN: And so, you have this array of functions and you just reduce over it and call them. Well, you return a function. So, it’s a higher function. You return a function that takes an argument then you reduce over the functions that came in as arguments and you call each one of them with whatever result was from the previous.

CHARLES: Right. Like Tracy mentioned in the pre-show, I’m an aspiring student of functional programming. So, would this be kind of like a monoid here where you’re mashing all these functions together? Is your empty value? I’m just going to throw it out there. I don’t know if it’s true or not, but that’s my conjecture.

BEN: Yes. Technically, it’s a monoid because it wouldn’t work unless it was a monoid. Because monoids, I believe the category theory I think for monoid is that monoids can be concatenated because they definitely have an end.

CHARLES: Right.

BEN: So, you would not be able to reduce over all those functions and build something with that, like that, unless it was a monoid. So yeah, the fact that there’s reduction involved is a cue that it’s a monoid.

CHARLES: Woohoo! Alright.

[Laughter]

CHARLES: Have you found yourself wanting to apply some of these more “rigorous” formalisms that you find out there in the development of RxJS or is that just really a secondary concern?

BEN: It’s a secondary concern. It’s not something that I like. It’s something I think about from time to time, when really, debating any kind of heavy issue, sometimes it’s helpful. But when it comes to teaching anybody anything, honestly the Haskell-isms and category theory names, all they do is just confuse people. And if you tell somebody something is a functor, they’re like, “What?” And if you just say it’s mappable, they’re like, “Oh, okay. I can map that.”

CHARLES: [Laughs] Right, right.

BEN: And then the purists would be like, “But they’re not the same thing.” And I would be like, “But the world doesn’t care. I’m sorry.”

CHARLES: Yeah, yeah. I’m kind of experiencing this debate myself. I’m not quite sure which side I fall on, because on the one hand it is arbitrary. Functor is a weird name. But I wish the concept of mappable existed. It does, but I feel like it would be handy if people… because there’s literally five things that are super handy, right? Like mappable, if we could have a name for monoid. But it’s like, really, you just need to think in terms of these five constructs for 99% of the stuff that you do. And so, I always wonder, where does that line lie? And how… mappable, is that really more accessible than functor? Or is that only because I was exposed to the concept of mapping for 10 years before I ever heard the F word.

BEN: Yes, and yes. I mean, that’s…

CHARLES: [Laughs]

BEN: Things that are more accessible are usually more accessible because of some pre-given knowledge, right? What works in JavaScript probably isn’t going to work in Haskell or Scala or something, right?

CHARLES: Mmhmm.

BEN: If someone’s a Java developer, certain idioms might not make sense to them that come from the JavaScript world.

CHARLES: Right. But if I was learning like a student, I would think mappable, I’d be thinking like, I would literally be thinking like Google Maps or something like that. I don’t know.

BEN: Right, right. I mean, look at C#. C#, a mapping function is always going to be called select, right, because that’s C#. That’s their idiom for the same thing.

CHARLES: Select?

BEN: Yeah.

CHARLES: Really?

BEN: Yeah, select. So, they’ll…

CHARLES: Which in Ruby is like find.

BEN: Yeah. there’s select and then, what’s the other one, ‘select many’ or something like that.

[Chuckles]

BEN: So, that’s C#.

CHARLES: Oh, like it’s select from SQL. Okay.

BEN: Yeah, I think that’s kind of where it came from because people had link and then they had link to SQL and then they’re like, well I want to do this with regular code, with just using some more… less nuanced expressions. So, I want to be able to do method calls and chain those together. And so, you end up with select functions. And I think that that exists even in Rx.NET, although I haven’t used Rx.NET.

CHARLES: Hmm, okay.

ELRICK: So, I know you do a lot of training with Rx. What are some of the concepts that people struggle with initially?

TRACY: I think when we’re teaching RX Workshop, a lot of the people sort of… I’ll even see senior level people struggle with explaining it, is the difference between observables and observers and then wrapping their head around the idea that, “Hey, observables are just functions in JavaScript.” So, they’re always thinking observables are going to do something for you. Actually, it’s not just in Angular but also in React, but whenever someone’s having issues with their Rx applications, it’s usually something that they’re like nesting observables or they’re not subscribing to something or they’ve sort of hot-messed themselves into a tangle. And I’m sure you’ve debugged a bunch of this stuff before. The first thing I always ask people is, “Have you subscribed?” Or maybe they’re using an Angular… they’re using pipes async but they’re also calling ‘dot subscribe’ on their observable.

BEN: Yeah. So, like in Angular they’ll do both. Yeah. There’s that. I think that, yeah, that relates to the problem of people not understanding that observables are really just functions. I keep saying that over and over again and people really don’t seem to take it to heart for whatever reason.

[Chuckles]

BEN: But you get an observable and when you’re chaining all those operators together, you’re making another observable or whatever, observables don’t do anything until you subscribe to them. They do nothing.

CHARLES: Shouldn’t they be called like subscribable?

BEN: Yes.

[Chuckles]

BEN: They probably should. But we do hand them an observer. So, you are observing something. But the point being is that they don’t do anything at all until you subscribe to them. And in that regard, they’re like functions, where functions don’t do anything unless you call them. So, what ends up happening with an observable is you subscribe to it. You give it an observer, three callbacks which are then coerced into an observer. And it takes that observer and it hands it to the body of this observable definition and literally has an observer inside of there. And then you basically execute that function synchronously and do things, whatever those things are, to set up some sort of observation. Maybe you spin up a WebSocket and tie into some events on it and call next on the observer to get values out of your observable. The point being that if you subscribe to an observable twice, it’s the same thing as calling a function twice. And for some reason, people have a hard time with that. They think, if I subscribe to the observable twice, I’ve only called the function once.

CHARLES: I experienced this confusion. And I remember the first time that that… like, I was playing with observables and the first time I actually discovered that, that it was actually calling my… now what do you call the function that you pass to the constructor that actually does, that calls next or that gets passed the observer?

TRACY: [Inaudible]

BEN: I like to call it an initialization function or something. But the official name from the TC39 proposal is subscriber function.

CHARLES: Subscriber function. So, like…

BEN: Yeah.

CHARLES: I definitely remember it was one of those [makes explosion sound] mind-blowing moments when I realized when I call my subscribe method, the entire observable got run from the very beginning. But my intuition was that this is an object. It’s got some shared state, like it’s this quasar that I’m now observing and I’m seeing the flashes of light coming off of it. But it’s still the same object. You think of it as having yeah, not as a function. Okay. No one ever described it to me as just a function. But I think I can see it now.

ELRICK: Yeah, me neither.

CHARLES: But yeah, you think of it in the same way that most people think of objects, as like, “I have this object. I have a reference to it.” Let observable equal new observable. It’s a single thing. It’s a single identity. And so, that’s the thing that I’m observing. It’s not that I’m invoking this observable to observe things. And I think that’s, yeah, that’s a subtle nuance there. I wish I had taken y’all’s course, I guess is what I’m saying.

ELRICK: Yeah.

BEN: Yeah. Well, I’ve done a few talks on it.

CHARLES: [Laughs]

BEN: I always try to tell people, “It’s just a function. It’s just a function.” I think what happens to a lot of people too is there’s the fact that it’s an object. But I think what it is, is people’s familiarity with promises does this. Because promises are always multicast. They are always “hot”. And the reason for this is because they’re eager. So, by the time you have a promise, whatever is producing value to the promise has already started. And that means that they’re inherently a multicast.

CHARLES: Right.

BEN: So, people are used to that behavior of, I can ‘then’ off of this promise and it always means one thing. And it’s like, yeah, because the one thing has nothing to do with the promise. It wasn’t [Chuckles]

CHARLES: Right.

BEN: This promise is just an interface for you to view something that happened in the past, where an observable is more low-level than that and more simple than that. It just states, “I’m a function that you call. I’m going to be able to do anything a function can do. And by the way, you’re giving me an observer and I’m going to do some stuff with that too and notify you via this observer that you handed me.” Because of that you could take an observable and close over something that had already started. Say you had a WebSocket that was already running. You could create a new observable and just like any function, close over that, externally create a WebSocket. And then everyone that subscribes to that observable is tying an observer to that same WebSocket. Then you’re multicast. Then you’re “hot”.

ELRICK: [Inaudible]

CHARLES: Right. So, I was going to say that’s the distinction that Jay was talking about. He was talking about we’re going to just talk about… he said at the very beginning, “We’re just going to talk about hot observable.”

ELRICK: Yup.

CHARLES: But even a hot observable is still theoretically evaluating every single time you subscribe. You’re getting a new observable. You’re evaluating that observable afresh each time. It just so happens that in the lexical scope of that observable subscriber function, there is this WebSocket?

BEN: Yeah. So, it’s the same thing. Imagine you wrote a function that when you called it created a new WebSocket and then… say, you wrote a new function that you gave an observer object to, right? An observer object has next, error, and complete. And in that function, when you called it, it created a new WebSocket and then it tied the ‘on message’ and ‘on close’ and whatever to your observer’s next method and your observer’s error message and so on. When you call that function, you would expect a new WebSocket to be created every single time. Now, let’s just say alternately you create a WebSocket and then you write a new function that that function closes over that WebSocket. So, you reference the WebSocket that you externally created inside of your function. When you call that function, it’s not going to create a new WebSocket every time. It’s just closing over it, right? So, even though they both are basically doing the same thing, now the latter one of those two things is basically a hot observable and the former is a cold observable. Because one is multicast which is, “I’m sharing this one WebSocket with everybody,” and the other one is unicast which is, “I am going to create a new WebSocket for each person that calls me.” And that’s the [inaudible] people have a hard time with.

CHARLES: Right. But really, it’s just a matter of scope.

BEN: Yeah. The thing people have a hard time with, with observables, is not realizing that they’re actually just functions.

CHARLES: Yeah. I just think that maybe… see, when I hear things like multicast and unicast, that makes me think of shared state, whereas when you say it’s just a matter of scope, well then I’m thinking more in terms of it being just a function. It just happens that this WebSocket was already [scoped].

BEN: Well, shared state is a matter of scope, right?

CHARLES: Yes, it is. It is. Oh, sorry. Shared state associated with some object identity, right?

BEN: Right.

CHARLES: But again, again, it’s just preconceptions, really. It’s just me thinking that I’ve had to manage lists of listeners and have multicast observers and single-cast observers and having to manage those lists and call notify on all of them. And that’s really not what’s happening at all.

BEN: Yeah. Well, I guess the real point is observables can have shared state or they could not have shared state. I think the most common version and the most composable version of them, they do not have any shared state. It’s just one of those things where just like a function can have shared state or it could be pure, right? There’s nothing wrong with either one of those two uses of a function. And there’s nothing wrong with either one of those two uses of Observable. So, honest to god, that is the biggest stumbling block I think that I see people have. That and if I had to characterize it I would say fear and loathing over the number of operators. People are like…

CHARLES: [Chuckles]

BEN: And they really think because everyone’s used to dealing with these frameworks where there’s an idiomatic way to do everything, they think there’s going to be an RxJS idiomatic way to do things. And that’s just patently false. That’s like saying there’s an idiomatic way to use functions. There’s not. Use it however it works. The end. It’s not…

CHARLES: Mmhmm, mmhmm.

BEN: You don’t have to use every operator in a specific way. You can use it however works for you and it’s fine.

ELRICK: I see that you guys are doing some fantastic work with your documentation. Was that part of RxJS 2.0 docs?

TRACY: I was trying to inspire people to take on the docs initiative because I think when I was starting to learn RxJS I would get really frustrated with the docs.

BEN: Yeah.

TRACY: I think the docs are greatly documented but at the same time if you’re not a senior developer who understands Rx already, then it’s not really helpful. Because it provides more of a reference point that the guys can go back and look at, or girls. So anyways, after many attempts of trying to get somebody to lead the project I just decided to lead the project myself.

[Laughter]

TRACY: And try to get… the community is interesting because I think because the docs can be sometimes confusing… Brian Troncone created LearnRxJS.io. There’s these other visualization projects like RxMarbles, RxViz, et cetera. And we just needed to stick everybody together. So, it’s been a project that I think has been going on for the past two months or so. We have… it’s just an Angular app so it’s probably one of the most easiest projects to contribute to. I remember the first time I tried to contribute to the Ember docs. It literally took me an hour to sit there with a learning team, Ember Learning Team member and… actually, maybe it was two hours, just to figure out how the heck… like all the things I had to download to get my environment set up so that I could actually even contribute to the darn documentation. But with the Rx, the current RxJS docs right now is just an Angular app. You can pull it down. It’s really easy. We even have people who are just working on accessibility, which is super cool, right? So, it’s a very friendly place for beginners.

BEN: I’m super pleased with all the people that have been working on that. Brian and everybody, especially on the accessibility front. Jen Luker [inaudible] came in and voluntarily… she’s like the stopgap for all accessibility to make sure everything is accessible before we release. So, that’s pretty exciting.

TRACY: Yeah.

ELRICK: Mmhmm.

TRACY: So funny because when me and Jen started talking, she was talking about something and then I was like, “Oh my god, I’m so excited about the docs.” She’s like, “I’m so excited, too! But I don’t really know why I’m excited. But you’re excited, so I’m excited. Why are you excited?”

[Laughter]

TRACY: I was like, “I don’t know. But I’m excited, too!”

[Chuckles]

TRACY: And then all of a sudden we have accessibility. [Laughs]

ELRICK: Mmhmm. Yeah, I saw some amazing screenshots. Has the new docs, have they been pushed up to the URL yet?

TRACY: Nah, they are about to. We were… we want to do one more accessibility run-through before we publish it. And then we’re going to document. We want to document the top 15 most viewed operators. But we should probably see that in the next two weeks or so, that the new docs will be… I mean, it’ll say “Beta, beta, beta” all over everything. But actually also, some of our friends, [Dmitri] from [Valas] Software, he is working on the translation portion to make it really easy for people to translate the docs.

CHARLES: Ah.

TRACY: So, a lot of that came from the inspiration from the Vue.js docs. we’re taking the versioning examples that Ember has done with their docs as inspiration to make sure that our versioning is really great. So, it’s great that we can lend upon all the other amazing ideas in the industry.

ELRICK: Oh, yeah.

CHARLES: Yeah, it’s fantastic. I can’t wait to see them.

ELRICK: Yeah, me neither. The screenshots look amazing. I was like, “Wow. These are some fabulous documentation that’s going to be coming out.” I can’t wait.

TRACY: Yeah. Thank you.

CHARLES: Setting the bar.

ELRICK: Really high.

[Laughter]

CHARLES: Actually, I’m curious. Because observables are so low-level, is there some use of them that… what’s the use of them that you found most surprising? Or, “Whoa, this was a crazy hack.”

BEN: The weirdest use of observables, there’s been quite a few odd ones. One of the ones that I did one time that is maybe in RxJS’s wheelhouse, it was just that RxJS already existed. So, I didn’t want to pull in another transducer library, was using RxJS as a transducer. Basically… in Netflix we had a situation where we had these huge, huge arrays of very large objects. And if you try to take something like that and then map it and then filter it and then map it and then filter it, we’re using Array map and filter, what ends up happening is you create all sorts of intermediary arrays in-memory. And then garbage collection has to come through and clean that up. And that locks your thread. And over time, we were experiencing slowness with this app. And it would just build up until eventually it ground to a halt. And I used RxJS because it was an available tool there to wrap these arrays in an observable and then perform operations on them step-by-step, the same map, filter, and so on. But when you do that, it doesn’t create intermediary arrays because it passes each value along step to step instead of producing an entire array and then doing another step and producing an entire array, and so on. So…

CHARLES: So, will you just…

BEN: It saved garbage collection and it increased the performance of the app. But that’s just in an extreme case. I would never do that with just regular arrays. If anything, it was because it was huge, huge arrays of very large objects.

CHARLES: So, you would create an observable our of the array and then just feed each element into the observable one at a time?

BEN: Well, no. If you say ‘observable from’ and you give it an array, that’s basically what it does.

CHARLES: Okay.

BEN: It loops over the array and nexts those values out of the array synchronously.

CHARLES: I see, I see.

BEN: So, it’s like having a for loop and then inside of that for loop saying, “Apply the map. Apply the filter,” whatever, to each value as they’re going through. But when you look at it, if you had array map, filter, reduce, it’s literally just taking the first step and saying ‘observable from’ and wrapping that array and then the rest of it’s still the same.

CHARLES: Right. Yeah. No, that’s really cool.

BEN: That was a weirder use of it. I’ve heard tell of other things where people used observables to do audio synchronization, which is pretty interesting. Because you have to be very precise with audio synchronization. So, hooking into some of the Web Audio APIs and that sort of thing. That’s pretty interesting. The WebSocket multiplexing is something I did at Netflix that’s a little bit avant-garde for observable use because you essentially have an observable that is your WebSocket. And then you create another observable that closes over that observable and sends messages over the WebSocket for what you’re subscribed to and not subscribed to. And it enables you to very easily retry connections and these sorts of things. I did a whole talk on that. That one’s pretty weird.

CHARLES: Yeah. Man, I [inaudible] to see that.

BEN: But in the general use case, you click a button, you make an AJAX request, and then you get that back and maybe you make another AJAX request. Or like drag and drop and these sorts of things where you’re coordinating multiple events together, is the general use case. The non-weird use case for RxJS. Tracy does weird stuff with RxJS though.

[Laughter]

CHARLES: Yeah, what’s some weird uses of RxJS?

TRACY: I think my favorite thing to do right now is to figure out how many different IoT-related things I can make work with RxJS. So, how many random things can I connect to an application using that?

BEN: Tracy’s projects are the best. They’re so good.

[Laughter]

TRACY: Well, Ben and I created an application where you can take pictures of things using the Google Image API and it’ll spit back a set of puns for you. So, you take a picture of a banana, it’ll give you banana puns. Or you can talk to it using the speech recognition API. My latest thing is I really want to figure out how to… I haven’t figured out if Bluetooth Low Energy is actually enabled on Google Home Minis. But I want to get my Google Home Mini to say ‘booty’. [Inaudible]

[Laughter]

CHARLES: RxJS to the rescue.

[Laughter]

BEN: Oh, there was, you remember Ng-Cruise. We did Ng-Cruise and on there, Alex Castillo brought…

TRACY: Oh, that was so cool.

BEN: All sorts of interesting… you could read your brain waves. Or there was another one that was, what is it, the Microsoft, that band put around your wrist that would sense what direction your arm was in and whether or not your hand was flexed. And people…

TRACY: Yeah, so you could flip through things.

BEN: Yeah. And people were using reactive programming with that to do things like grab a ball on the screen. Or you could concentrate on an image and see if it went blurry or not.

ELRICK: Well, for like, Minority Report.

BEN: Oh, yeah, yeah. Literally, watching a machine read your mind with observables. That was pretty cool. That’s got to be the weirdest.

TRACY: Yeah, or we had somebody play the piano while they were wearing one of the brainwave… it’s called the OpenBCI project is what it is. And what you can do is you can actually get the instructions to 3D print out your own headset and then buy the technology that allows you to read brain waves. And so with that, it’s like… I mean, it was really awesome to watch her play the piano and just see how her brain waves were going super crazy. But there’s also these really cool… I don’t know if you guys have heard of Jewelbots, but they’re these programmable friendship bracelets that are just little Arduino devices that light up. I have two of them. I haven’t even opened them.

CHARLES: [Laughs]

TRACY: I’ve been waiting to play with them with you. I don’t know what we’re going to do, but I just want to send you lights. Flashing lights.

[Laughter]

TRACY: Morse code ask you questions about RxJS while you’re working.

[Laughter]

CHARLES: Yeah. Critical bug. Toot-toot-toot-too-too-too-too-toot-toot.

[Laughter]

CHARLES: RxJS Justice League.

TRACY: That would actually be really fun.

[Laughter]

TRACY: That would be really fun. I actually really want to do that. But…

CHARLES: I’m sure the next time we talk, you will have.

TRACY: [Laughs] Yes. Yes, yes, yes, I know. I know. we’ll do it soon. We just need to find some time while we’re not going crazy with conferences and stuff like that.

CHARLES: So, before we head out, is there any upcoming events, talks, releases, anything that we ought to be, we or the listeners, ought to be aware of?

TRACY: Yeah, so one of the things is that Ben and I this weekend actually just recorded the latest version of RX Workshop. So, if you want to learn all about the latest, latest, newest new, you can go ahead and take that course. We go through a lot of different things like multiplex WebSockets, building an application. Everywhere from the fundamentals to the more real world implementations of RxJS.

BEN: Yeah. Even in the fundamentals area, we’ve had friends of ours that are definitely seasoned Rx veterans come to the workshop. And most of them ask the most questions while talking about the fundamentals. Because I tend to dig into, either deep into the internals or into the why’s and how’s thing. Why and how things work. Even when it comes to how to subscribe to an observable. Deep detailed information about what happens if you don’t provide an error handler and certain cases and how that’s going to change in upcoming versions, and why that’s changing in upcoming versions, and what the TC39’s thoughts are on that, and so on and so forth. So, I try to get into some deeper stuff and we have a lot of fun. And we tend to be a little goofier at the workshops from time to time than we were in this podcast. Tracy and I get silly when we’re together.

TRACY: It’s very true.

[Laughter]

TRACY: But I think also, soon I think there are people that are going to be championing an Observable proposal on what [inaudible]. So, aside from the TC39 Observable proposal that’s currently still at stage one, I don’t know Ben if you want to talk a little bit about that.

BEN: Oh, yeah. So, I’ve been involved in conversations with folks from Netflix and Google as well, Chrome team and TC39 members, about getting the WHATWG, the ‘what wig’, they’re a standards body similar to W3C, to include observables as part of the DOM. The post has not been made yet. But the post is going to be made soon as long as everybody’s okay with it. And what it boils down to is the idea of using observables as part of event targets. An event target is the API we’re all familiar with for ‘add event listener’, ‘remove event listener’. So, pretty much anywhere you’d see those methods, there might also someday be an on method that would return an observable of events. So, it’s really, really interesting thing because it would bring at least the primitives of reactive programming to the browser. And at the very least it would provide maybe a nicer API for people to subscribe to events coming from different DOM elements. Because ‘add event listener’ and ‘remove event listener’ are a little unergonomic at times, right?

CHARLES: Yeah. They’re the worst.

BEN: Yeah.

CHARLES: That’s a very polite way of putting it.

BEN: [Chuckles] So, that’s one thing that’s coming down the pipe. Other things, RxJS 6 is in the works. We recently tied off 5.5 in a stable branch. And master is now our alpha that we’re working on. So, there’s going to be a lot of refactoring and changes there, trying to make the library smaller and smaller. And trying to eliminate some of the footprints that maybe people had in previous versions. So, moving things around so people aren’t importing stuff that were meant to be implementation details, reducing the size of the library, trying to eliminate some bloat, that sort of thing. I’m pretty excited about that. But that’s going to be in alpha ongoing for a while. And then hopefully we’ll be able to move into beta mid first quarter next year. And then when that’ll be out of beta, who knows? It all depends on how well people like the beta and the alpha, right?

CHARLES: Alright. Well, so if folks do want to follow up with y’all either in regards to the course or to upcoming releases or any of the other great stuff that’s coming along, how would they get in touch with y’all?

TRACY: You can find me on Twitter @ladyleet. But Ben is @BenLesh. RX Workshop is RXWorkshop.com. I think in January we’re going to be doing state of JavaScript under This Dot Media again. So, that’s where all the core contributors of different frameworks and libraries come together. So, we’ll definitely be giving a state of RxJS at that time. And next year also Contributor Days will be happening. So, if you go to ContributorDays.com you can see the previous RxJS Contributor Days and figure out how to get involved. So, we’re always open and happy and willing to teach everybody. And again, if you want to get involved it doesn’t matter whether you have little experience or lots of experience. We are always willing to show you how you can play.

BEN: Yeah. You can always find us on Twitter. And don’t forget that if you don’t find Tracy or I on Twitter, you can always message Jay Phelps on Twitter. That’s important. @_JayPhelps. Really.

TRACY: Yeah.

[Laughter]

BEN: You’ll find us.

CHARLES: [Chuckles] Look for Jay in the show notes.

[Laughter]

CHARLES: Alright. Well, thank you so much for all the stuff that y’all do, code and otherwise. And thank you so much Ben, thank you so much Tracy, for coming on the show.

BEN: Thank you.

CHARLES: Bye Elrick and bye everybody. If you want to reach out to us, you can always get in touch with us at @TheFrontside or send us an email at contact@frontside.io. Alright everybody, we’ll see you next week.