EPISODE 1849

[INTRODUCTION]

[0:00:01] ANNOUNCER: RxJS is an open-source library for composing asynchronous and event-based programs. It provides powerful operators for transforming, filtering, combining, and managing streams of data, from user input and web requests to real-time updates. Ben Lesh is the creator of RxJS. He joins Josh Goldberg to talk about his path into engineering and the RxJS library.

This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ES Slint, the tooling that enables ES Slint and Prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on Blue Sky, Mastodon, Twitter, Twitch, YouTube, and .com as Joshua K. Goldberg.

[INTERVIEW]

[0:01:10] JG: Ben Lesh, welcome to Software Engineering Daily.

[0:01:13] BL: Hey, thanks for having me. I haven't seen you in a while.

[0:01:15] JG: Yeah. It's been a bit. I'm excited to talk to you. You've been doing a lot of really interesting stuff around observables and RxJS. Before we get into all that, can you tell us, how did you get into coding?

[0:01:24] BL: Well, let's see. I had been doing little basic programming stuff when I was a kid. But then, I went to art school. Dropped out of art school after about three years, and was working doing graphic design work at Ohio State University, working there. I was not going to school there. There's a situation where someone was working on a website or whatever, and I was curious about it, and I thought I could fix something, or work on it. Basically, I learned how to do some basic HTML and JavaScript stuff. I had a friend that was like, "Dude, do you know how much more money you can make doing this?" I was like "Really?"

At the time, there was no Google, there was no Stack Overflow, none of that. I basically loitered in Barnes & Noble and read books, because that was the only way to get recent information. They weren't at the library or anything. Practice doing stuff on my little Compaq Presario. Eventually, I got my first programming gig. There was an ad. They were trying to hire somebody for, it was like 80 bucks an hour, or something like that for four hours a day. I had to call them over and over and over again, because they were not calling me back, because I wasn't qualified for what they were looking for.

They finally brought me in, and they asked me some questions. I got probably half of them right, and they were like, "So, you know what we're going to ask to be like?" I was like, "Do you think you're qualified for this?" I was like, "Well, no. But I really think I can do what you need done, and I'm willing to learn and I'll work for $10 an hour." If I work for two days and you don't like me, then you've only paid me for what you're going to pay somebody else for one hour, and you could probably even still hire that person if you wanted. They liked that answer, and I got the job. It was a one-month contract, which is I think why it was open for so long. They kept me for three months, or something like that, and they gave me a letter of recommendation, because I asked for one. After that, I got other programming jobs, and the pay was higher and everything.

[0:03:20] JG: That's a fascinating interview technique, to offer to undersell.

[0:03:24] BL: Yeah. Yeah. I mean, you can get away with it when you're - how old was I? I was 20, I think. 19, 20.

[0:03:34] JG: What tech stack was that? I'm just curious.

[0:03:36] BL: The first gig, actually it was a lot of HTML and JavaScript. The JavaScript was funny. The very first thing I had to write was they wanted - people don't remember this, probably, but there's a thing, and still exists. If you get into any browser and you say, window.status, there's just an empty string there. There used to be this property in window. You could set called window.status, and you set it to any string. You know when you hover over a link modern times, it shows a little, like the URL underneath, on the bottom of the poll page. That was the status bar. You used to be able to set that manually with window.status.

They stopped allowing people to do that, because it was a way that you could be like, ha, ha. You're going to click on this link, and it's not actually the link, because someone was setting it. It was like a security hole. What I was tasked with doing was making a little ticker that played in that window.status of all the deals that were going on in this e-commerce site that day. I learned about set interval there. That was the first time I reset interval, and I had to slice a string and make it tick along and continuously wrap. That was the first professional problem I ever solved.

[0:04:47] JG: It's getting a ticker at the bottom of the page with a now deprecated API.

[0:04:50] BL: Right. Yeah. Yeah. But you can get the string off of it if you want. The empty string is still there.

[0:04:56] JG: That's representative of what you're known for in the web community now. You're doing some timing, some streaming data shenanigan and JavaScript with bizarre APIs. How did you go from that to working on libraries, like RxJS?

[0:05:09] BL: Oh, boy. It's a long path. After that job, I was doing Visual Basic programming and ASP. Classic, they would call it now, but at the time it was just ASP. Got into doing .NET development, did that for 10 years. The reason I got into JavaScript development was around the time Angular was new, we were trying to build - I was working at a company that were doing pharmaceutical robotics. They were trying to build this client that was very rich and features. There was this belief amongst software engineers at the time that JavaScript was a joke, it was a joke language. You could never make good money doing that. It was not the work that you wanted to land on.

I was like, all right. At the time, I was the senior engineer on that team and I'm like, that's fine. I'll do this work. I don't care. This was back when you had to concatenate your JavaScript files yourself and all these other things. You had to basically build your own build tools. That's how I got into it. I had to answer a bunch of questions on Stack Overflow about Angular, to learn things about Angular. I'd find ones that I didn't know the answer to, figure out the answer and answer it. It just so happens that that meant that I was one of the top answerers on Stack Overflow. Someone at Netflix was building something with Angular, or trying to build something with Angular. They saw my name over and over and over again and they said, "Hey, why don't 

we see if we can get this guy to come work for us."

I thought it was a joke. I got this email from Netflix and I thought it was one of my friends screwing with me. Netflix was like, "Hey, we're just randomly reaching out to you to see if you're interested in working for us, kind of thing," right? I didn't apply. I went and I was like, all right, I'm going to go to this interview. I'm going to have a phone conversation. That's what I thought. I had a phone conversation with this person. I was very honest with them about my level of ability, or whatever. They were like, "Well, great. We'll have you come out." I'm like, "Okay, cool."

I've never been to California. Living in Pennsylvania at the time. Mostly spent time in Ohio, Michigan, Pennsylvania. I was like, okay. I get a free trip to California. That's probably all this is going to amount to. I'll get a little tour of Netflix. That'll be awesome. Then, the next thing you know, one of the, I think, the VP of engineering or somebody was walking me out to the front door, talking positive, I'm like, "Okay, so I'm going to get an offer, but there's no way it's going to be enough to get my family to move to the most expensive place in America to live." Then it was.

I ended up at Netflix. At Netflix, this is a really long story, I told you. We're going to get to the RxJS thing. Netflix was my first introduction to RxJS. I'd never seen it before. I started using it for some things as I started to understand it better and was working on real-time streaming dashboards. Netflix, the RxJS really helped with memory management in this really busy streaming dashboards of charts and things. Of course, the updating streams and all of that. There is a feature that we needed. It was a re, I think, retry when. I added that feature through open source, and I'd also done a lot of work in open source on the Angular code base at the time, too, even though I was working in Ember at Netflix, which is funny.

Yeah. Since I had a lot of open-source experience, I was approached by Geoffrey Hussein, who worked at Netflix at the time, and Eric Meyer, the guy who invented observables, and this guy named Ben Christensen, who worked on RxJava, who worked down the aisle for me. They came over and they said, "Hey, we want to talk to you." They said, they wanted me to work on RxJS, like to rewrite it. I told them I was not qualified. I told them, they should give him a list of other people they should pick. They were insistent, because of my open-source experience. The rest is stuff that people know, I think. But yeah, that was 11 years ago almost now.

[0:08:55] JG: Yeah. Wow. On the reactive dash extensions/RxJS GitHub, we see issue number 482 and pull request number 486, yeah, over a decade ago. That's incredible. I also love that you've now used another interesting technique. Stack Overflow as a form of development, that a lot of this was started in part by you finding questions you did not know the answer to and answering them. That's a powerful technique.

[0:09:21] BL: Yeah. Well, I mean, what I tell people, I don't know that you could still use Stack Overflow for that now, but what people should do if they want to make it somewhere is be conspicuously helpful. Right now, the climate's pretty weird right now. I feel like, all of the really popular developers are these loud bombastic people on YouTube, or whatever. I wouldn't classify them as being helpful all the time. Sometimes they're the opposite of that, I think. There are some of the information they give out is helpful and giving information to people in general is helpful, I guess.

I think that being conspicuously helpful, either in your own community and giving talks, writing blog articles, whatever you can do, or just answering people's questions and being nice and that sort of thing is really a pathway to success. You're going to be a lot luckier in your career if everyone knows that you know things and everyone thinks that you're useful and helpful. Than if you just sit and be quiet and keep your head down and that sort of thing. In stack overflow, it wasn't intentional on my part. It was more just like, I want to be helpful and I want to learn the answer to this question. Therefore, I'm picking out interesting questions and seeing if I can figure out the answer.

[0:10:35] JG: We're going to talk about RxJS, but I have to agree with you for a brief moment that there's this growing area of developers who are technical, who create content, content creators. It's a very different thing to be a great content creator versus a great, let's say, contributor. A lot of overlap, a lot of people who do both. But it is two similar areas, similar to how front end and full stack are similar areas. It can be hard, I think, for people to understand when someone is speaking as a content creator, just to spread information, versus educating, helping best practices get spread, or even fall.

[0:11:10] BL: There's a heavy monetary component to the content creation thing too, right? It's not just people out there, like I'm curious and I want to be helpful. Therefore, I'm out there doing things. Ideally, I get rewarded in some way by my getting a better job, or something at some point. But these are folks literally making money off of the number of views they get for things, which is it's a different kind of incentive. It's probably less incentive to be helpful anyways. Unless, the helpfulness is the reason people are showing up to your channel, I suppose.

I'm a little bit cynical about it. I have children. I've watched my children's brains rot watching weird, short things on YouTube. I hear the word YouTube and I'm just, "Ugh." I shudder a little bit. It's just because I'm - I think I'm just getting old and cranky when it comes to that thing. Yeah.

[0:12:06] JG: Old and cranky, he says with a happy smile and laughter. Let's simulate Stack Overflow for a bit, the heyday of Stack Overflow. I'd like to ask you a few questions. To start, let's say that you find someone has asked, what is RxJS and why would I want to use it? How would you answer a question like that?

[0:12:22] BL: Oh, boy. Well, I mean, first of all, I know the answer to that question, but I would probably just start off with you look at that thing and you're like, all right, so most people don't want to hold book. Or they do want the book, but they need the summary. You start off with some bullet points, like RxJS is about streaming data, RxJS is the opposite of iterables. RxJS is a cancelable asynchronous type for zero to N values. You can just start off with those simple bullet points, and then dive deeper into what each one of those things actually means. Like, what is asynchronous data? How is it the opposite of iterables? Why is cancellation important? Those sorts of things.

You can come up with something that might take somebody a couple hours to read if you really wanted to get into the whole details of it. The important thing is that people get the very, very high-level bits of it, and why they would reach for that particular type, or push versus pull, and some of these other things.

[0:13:24] JG: Yeah. That's a great segue. The next question is, I've heard of these things that RxJS sounds like, but I don't understand the difference. What is the difference between an iterable and something that's provided by RxJS?

[0:13:36] BL: Oh, okay. Well, so an iterable, we use those all the time. If you use a for of loop, that's using an iterable. You've got this, and I know this, but this is obviously -

[0:13:46] JG: Sure. Simulated.

[0:13:48] BL: Yeah. An iterable, if you use a for of loop, what it's doing is it's taking the object on the right side of that of, and it's saying, "Hey, give me your iterator," and it calls the symbol.iterator thing. This iterator comes out, and all the iterator is, is just an object, basically, with a next method on it. For every loop through, it calls next, and it gets back a result that says, it has a value and says whether or not it's done. If it's done, the loop stops. If it's not done, it takes the value and goes into the loop. What you're doing then is you're pulling values out when you iterate.

You as the consumer, or the person that wants the data is saying, oh, I'm going to do something. Okay, give me the next one. You pull it out. Then you say, I want some data. You say, okay, give me the next one. You pull it out. Now an observable is exactly the opposite of that, where you subscribe and you give it a function that is your next. It calls your function when it has the next value. Instead of you, the producer saying, or the consumer saying, "I'm going to do something. I'm ready. Give me the next value," you're saying, "I'm waiting for you to give me a value, and I will do something with it when you give it to me." That's more like an event. Any event that you might have, like a click events, or mouse movements, or even getting a HTTP back, or something like that, those are all can be modeled as an observable. That's the main difference is one is you're pulling values out and the other one's pushing values at you. 

[0:15:11] JG: That push versus pull description makes a lot of sense, I think. A friend, who has extra time, I think he gave a fantastic talk on this at Revo JS 2023 on pushing and pulling in JavaScript. Another topic that comes up a lot in the context of pushing and pulling is observables. Now, you've been working on observables. Can you define for us what does it mean to work on an observable, or even what an observable is?

[0:15:34] BL: Okay. Well, observables were the original team that created this was at Microsoft under Eric Meyer. Literally, they went at it from an academic standpoint and were like, what if we took an iterable and pulled it inside out, made the dual of it, if you will, and made this pull-base type, the iterable into this push-base type observable. That's how it started. Or another way to go about it is if you've ever seen the observer pattern, people don't realize, but they use it all the time. The observer pattern, there's two things. There's a subject and there's an observer. The subject is shaped like ad observer, remove observer, and notify. Those are the three things on a subject.

It does what you would think, where the observer then has a notify on it. That's all it has. You take this observer, you give it to the subject, and then the subject when by adding it or whatever, and the subject whenever is notified will notify all the observers of that subject, right? It starts with that. But there's a missing piece in here, where you can functionally chain any subject to any observer by chaining them together. The way you do that actually is with observables. People don't often think about it. But an observable really, what it is is you have this type that when you subscribe to it, it executes a function internally and says, "Hey, create a producer. Here is this observer for you to next values into, or call next on whenever you get a value or a call, error, complete, or whatever, but we'll just focus on the next part of it."

What happens is when you subscribe, it calls that function, creates the producer, producer starts the nexting values. Then when you unsubscribe, there's some tear down logic that you've registered in there that will say, "Oh, I know how to tear this down." If it's a web socket, you might close it. If it's a mutation observer, or whatever, you might disconnect it, that sort of thing.

It's a really, really, really simplified type, the observable itself in its raw form. It exists in every single language that exists as far as I'm aware of. Well, every Turing complete programming language anyway. Not one in CSS, or something. It's really, really, really simplified type. It's used for a great number of things, which is why it's being moved, or been put through standards bodies, and it's being now added to the browser.

[0:18:00] JG: That's a fascinating process that I think would be interesting to walk through, because for a very long time, as you said, this was just a common practice in a lot of libraries. RxJS is to many understanding, that the most common, the very popular way to do observables. What is it about observables that you think has made it so that people not just want to do it, but want to standardize it in the web altogether?

[0:18:22] BL: I think the most powerful thing about it, there's several powerful things about it, but one of the things that's interesting for folks is if you've got an iterable, an iterable is a set of things as we know. It's like, an array can be an iterable. A number of different things can be an iterable. An iterable is a set of things. If you have an observable, it's also a set of things, but it's a set of things over time. What's true about sets of things is let's just say, you have a basket, a basket can contain a set of things. If you have a container for a set of things, like an observable, or an iterable, or a basket, you can take a basket of apples and create a basket of sliced apples, by putting it through some mapping process of slicing it, right? You can take a basket of apples and make a basket of not rotten apples by filtering out all of the rotten apples.

You can do the same thing. Here's obviously, arrays and iterables have map and filter, flat map and these other operations. All of those same operations exist on observables, but the difference is the observables are events. Now all of a sudden, you can take events and coordinate them together with these same operations you would use on these static synchronous sets. That's the biggest thing, I think, that attracts people to it initially.

Now, what I also know is, and this is one of the reasons we liked it at Netflix, was it also has this very deterministic teardown feature, where when you're not subscribing, it tears everything down. If you chain a whole bunch of other stuff together, it will automatically tear everything down. If you have a retry, it will tear everything down and stand it all back up again. You have this deterministic memory management that gets really, really hard when you're manually coding events together, where you might have to be like, "Oh, if I get this, then I have to subscribe to this. I have to start this web socket. When I get this message, I have to send this HTTP request, or whatever." All of those things, if they're mid-flight, become very difficult to make sure that you get all of those things torn down appropriately, if you're manually writing it. Where if they're all wrapped in observables, it's almost like having a finely block in every bit of your code to make sure that things are being torn down.

[0:20:28] JG: Yeah. I can see why that would make for a much cleaner code, both to write and read. Using the example you brought up of your very first experience, a little ticker at the bottom, that brings up a lot of the concepts of observables and piping through, where you need to start something, you need to update on an interval, you have constant actionings, Then at some point, you might want to dispose of it.

[0:20:47] BL: Or start it back over again, like repeated, or whatever. Yeah. Now, easier to read, that's in the eye of the beholder, as with all code. But so RxJS does have a bad name to some folks. The reason is, honestly, async programming is really hard. There's no way around it. You're taking asynchronous programming with iterables, or anything else. You're doing if this, then this, if this, then this, and you can read it top to bottom, left to right, no problem. Asynchronous programming, even with for await, you go down, you get to an await statement, and it goes off into the universe. It's not on your page of code anymore. It could be doing literally anything at that point. You could be awaiting a message coming from Saturn. Who knows what that's doing? It could fail or not fail.

Every single bit of asynchronous code, it goes off to some Schrodinger's cat problem and then comes back, and then you continue on your way. You can even do something, where you do asynchronous code, it makes a call out. Since you've left that synchronous code block, you can become re-entrant, where that call out actually comes back into the top of the same function. If you've got any shared state, you've got an issue. That's not a problem that's unique to RxJS. However, RxJS makes asynchronous work so easy that people create those problems, I think, easier, because they're doing more asynchronous stuff, a smaller amount of space, and then they build more complex, asynchronous things. Yeah, it becomes difficult.

Then the other thing is, if you don't understand what a flat map is, you're going to have a hard time. It's something I hear fewer complaints about people who do or don't understand the operators anymore, because it's been around so long, and I think a lot of people have exposure to it now. That's not to say that I haven't seen some absolutely abhorrent code, where people were using RxJS for things that they should not be using it for. Completely synchronous things. They'll be like, "Yeah, let's just wrap this in observables," and you're like, "No, dude. This is just, you're going over arrays. Just do array stuff. You'll be fine."

You made one request to one HTTP endpoint, it's okay if you don't cancel it when you're no longer using it. It'll just come back. Yeah, it'll eat some resources for a second, but it's probably not the end of the world. There's a give and take there.

[0:23:06] JG: How do I know whether the app I'm working on is a suitable candidate for updating to RxJS, or upgrading?

[0:23:12] BL: Observables, let's just talk about observable itself, and not all the operators. Just observables. Observables are good candidates for anything where you get more than one value, or maybe no values, synchronous or asynchronous, it doesn't matter. They're a good candidate for things where you could get no values, you could get multiple values, asynchronous, usually, ideally. Then, the other thing they're good for is cancellation. Promises have no cancellation. If you have a promise in flight, it must resolve, or reject. You can't just be like, "Oh, this is done now."

If you have it resolved with null, so it's not annoying, then you've got to handle that null every single place that you could be using that promise. Therefore, you have to reject it. But now you have this error that you have to handle, and you have to look and be like, is this an abort error, or is it an actual error? Then, you have to handle it appropriately. Promises, they're not truly cancelable without a lot of annoying steps, and observables don't have that problem. Observables are more like, this is a push-based type, you cancel it, it's done. It just silence, it tears everything down, finalizes itself, or whatever it needs to do, and carries on with life. Anything where you need some cancellation, observables are really, really good for that. Of course, things with zero to end values.

Now, then you get into the operators and stuff, and if you're doing a lot of coordination of events, like say, you've got two streams of data coming in, and you have to make sure that they line up, observables are really, really good at that, because we have these operators where they can, like RxJS has zip. They can zip things together. Or you can take a stream of data, and you can switch another stream of data to a different stream of data every single time. It's really, really good at event coordination. If you don't have a lot of events to coordinate, and you don't have any cancellation, it's probably okay. You don't really need to use observables for it.

[0:25:06] JG: My little app that renders a chart when I click a button might not need it, but your rich data visualization platform, or your Netflix dashboard, perhaps would be a better candidate?

[0:25:16] BL: Yeah, for sure. For sure. Even if it's not a real-time updating dashboard, if you're in a situation where you're like, look, I just kicked off 12 network requests. When they come back, they're all going to do something heavy, like try to update a chart. I know that the user might click away and unmount all those things. You probably want to make sure that those 12 network requests are cancelable. That doesn't mean you're going to tell the server to not respond, it just means you want to tell the browser, "Hey, this fetch here is done, or this XHR is aborted." Do not do anything with this. Don't even attempt to parse it, or read the headers, or anything. Just forget it. You've got one thread in web development, so it can get a little heavy if the app is busy enough.

[0:26:04] JG: Sure. Which is, by the way, I think a lot of web developers don't pick up on, because most of the time we have no need for this. You can abort fetch requests, XML HTTP requests in the standard DOM. That's actually a feature.

[0:26:17] BL: Yeah. Yeah, yeah. For a while, the fetch for a while did not have abort. They added abort signals for that purpose. XHR always had an abort. It always had one. The XHR was the only cancelable way to make one of these requests. It does have impact. Again, if you're making a bunch of requests, there's a difference between saying, oh, it came back, forget it, like you would do with the old fetch before abort existed, and abort to stop. Because one, it's still going to do a bunch of work before it gets to your code, and you can tell it to drop it, and it'll have put things in memory that need to be garbage collected on the same thread. It'll have done a bunch of processing in the same thread. Probably done some JSON parsing, which is slow as dirt on the same thread. It's not ideal.

In most cases, like you said, it doesn't matter. It's fine. In most cases, it's not a big deal. Then, anywhere that I'm going to be working, where I'm working on something that's got more intense problems than make one call, load a list of stuff on a page, yeah, they probably need cancellation, or some other nicer mechanisms for handling that stuff.

[0:27:26] JG: I'm going to want to talk about the future of RxJS. But before you, I can't resist gloating, or expressing over the operators page in the RxJS docs. You have a very lovely website, RxJS.dev, with a guide that goes over all sorts of articles and information and full docs on all the things you can get from RxJS. Honestly, very well written. A lot of the pages, especially the subscription page, I found to be very useful. But the operators page is one of the biggest lists of just all these different functions and there's Ajax and bind callback and minute callback. It makes sense what's stated in the front page, the introduction RxJS of think of RxJS as Lodash for events. You have every possible conceivable event handler in there. Do you have thoughts on the plethora of stuff provided by RxJS for events?

[0:28:17] BL: I don't like most of them. No, because all right, so I inherited this. This is RxJS is not my creation. RxJS started at Microsoft and was actually, this is the truth, was actually, it was written as a build target for Microsoft Project Volta, which predates TypeScript by a bit. The idea there was you write stuff in C-sharp and then compile it, you write .NET code and you compile it to JavaScript. They needed build targets for Rx.NET, which was very popular at the time. RxJS was up there. They had things like, oh, what is it, the same thread scheduler and stuff. There's only one thread, what are you talking about? They had all this other, like these weird names for things. It was very much, because it was a build target for that.

It came from this compiled language, where it didn't matter how many methods there were on something, because the compiler would remove everything you didn't use, right? To JavaScript land where the versions of RxJS before, what I worked on it would just be all of these operators are on prototype for observable and therefore, you get all of them. Boom, the bundle is now this big. That was one of the things that we had changed. Every operator, you see their window, window, window when, window time, all of these different window things, which I've never seen anyone use, I don't think. Those all came from this original implementation.

I'll be dead honest, I don't even think I can name all the operators if I had to. I'd be closer than a lot of people, but I think I'd miss a few. I think that I could get by with probably 10 to 12 of them realistically out of a list of 80, or however many there are. That's what I think about it. I am happy that what's being offered in the browser is a more minimal, but important list of things. RxJS will still be necessary for people to really get the full power of observables, I think, until I can convince them to add just a couple more features.

Yeah. When I see that huge list, I just think, if I could get away with it and I can't, because it's so widely used, I would slowly trim away at a lot of these things. I have to some degree, but there's just, I mean, there's only so many ways that you can write window when. It's there. It doesn't need a lot of maintenance. Will it be in future versions if I have to rewrite RxJS for this new observable for the platform? Will window when be there? Probably not. But that doesn't mean the previous version of RxJS won't still be actively maintained, because there's so many people using it.

[0:31:00] JG: TBD on whether every single one of them will exist is what I'm hearing.

[0:31:02] BL: Right. Yeah, yeah. I'm sure I'll get people that are really excited to contribute that want to add it, but whether or not they can prove to me that we actually need it out in the world, like, eh. The most telling thing is when I worked at Google, I could look through hundreds of thousands of build targets that use RxJS and see what they actually used. I know which ones are used and which ones aren't used that often. Some of these people were RxJS nuts. They were so crazy to use RxJS for things. They tried to use all the operators. The window when I'm picking out in particular, because I recall no one using window out of all of that. They use buffer. They use all the different buffers and all these different things. They use every other operator. I remember window in particular, I didn't find too many instances of at the time.

[0:31:52] JG: Is there an operator called instance of? Wondering if that's an accidental pun you made? Is observable instance in the top? Okay. But no, let's talk about this, actually. For some time, I remember on social media, there was a small push to try to get observables built into JavaScript through TC39. That's not what's currently happening, but it's still happening in some form. What's going on with observables?

[0:32:15] BL: Right. Observables are being standardized through the W3C, the WHATWG added to the browser. They're being added to the browser in that anything that's an event target, so buttons, or anything where there's add event listener, remove event listener, will now have a when method on it. You can say, when click, and it will give you an observable of clicks. The advantage to using said observable of clicks is when you subscribe to it N times, it only really actually adds one listener. It's multi-casting that.

The observables for the for the web platform are a little bit different than the ones from RxJS and that they are multi-cast by default, which means they're reference counted. Like, if you have a bunch of subscribers to it and it'll wait for all of them to unsubscribe before it removes that event listener. It's very useful for that. It's going to be useful for a variety of other things, like you can then do the classic idiomatic RxJS example of like, when you mouse down on this thing, you take all of the mouse movements until there's a mouse up, and you can now create some draggable elements, or some movable thing, or you can draw on a canvas, or whatever you want to do with that information.

That's the use case that it has built in. Then, of course, it has the type where you can create it your own observable. It's got all of the important operators on. It's got map and filter and these things. That's how it's landed. That is the result of about 10 years ago, it was in the TC39 proposal that stalled. The idea was put forth that, well, there's no - we need a use case to add this thing to JavaScript. We can't add this thing to JavaScript without a known use case. They're like, well, the best use case is probably event target. Why don't you try it over at the W3C? That's what happened.

Five or six years ago, I was tasked to write up a proposal while I was working at Google. I think their proposal number was 544, or something like that. It was this hugely like, it's got tons and tons of thumbs ups and rocket ship, whatever emojis that people add to GitHub issues, probably more than any other issue that they've had. Then we had to make the case for it. The case was made that these things exist everywhere, because over that period of time, the usership for RxJS not only gone upwards, but there was tons and tons of libraries that are widely used, like React router and Vue to some degree, and I'm trying to think, Svelt, that had their own observables inside of them. Relay had its own observable inside of it.

They were indistinguishable from the RxJS observable, except for their own little proprietary things, because they needed them for various purposes. If you go to the read me on the proposal, you can see all the uses of it. The other thing is I could say, what is it? Two or three years ago, I looked in the overall downloads of RxJS since I had started working on it, it was up over 2 billion total for the time that it existed. The number of total downloads every year is still more than all of the frameworks added together. There's a lot of evidence that people want to use observables for things, even though there's plenty of people, loud people out there like, "Oh, observables are the worst." Developers are really bad. I can tell you that. But observables themselves, they've never heard anybody on their own. It was always in the developer that heard somebody with them. There's a lot of that.

The TC39 process and the W3C process are very different. The W3C, WHATWG stuff, I think you need to have, and someone can correct me if I'm wrong about that. But I think you need to have two implementers, people that actually create browsers interested in this in order to proceed to the very first stage. Then after they're interested, you go to something like TPAC, it's discussed, there's a proposal, all this other stuff. Then an implementer implements it and they put it behind a flag. There's some discussion and more discussion, and so on. That's where we're at. Right now, it's very, very close to being released. It's already been announced that we're going to try to land it here in, I think, Chromium 133, or something like that.

[0:36:32] JG: That's very exciting.

[0:36:33] BL: Yeah. That makes it available in Chromium and Edge and whatever the newer Electron is that comes out after that. Firefox and Safari and Opera, all those folks are interested in it as well, but I don't know when they'll get to it. They've been a little slower to release features. It's not their fault. It's just how things shake out, I suppose. They definitely all have interest, all those people who were involved in the discussions that I was in.

Then, the only other thing that needs to be done is it needs to be added to Node, who has vested interest in wanting it in there, because they have event target as well. After that, it'll be everywhere, if not in some browsers that are slow to catch up, but the polyfill is pretty small.

[0:37:15] JG: This is what you mentioned earlier, that the core API, the stuff that you don't wrinkle your nose at is not that much stuff. But from those very bare primitives, you're able to create a lot of really beautiful logic with the observables.

[0:37:28] BL: Right. Right, right. Yeah. Almost everything I would want to use is there. You've got your finally in your catch, and instead of tap, we have inspect, I think. There's some really good stuff in there. The only stuff that we don't really have yet that does belong, but it's not there right now is there's no concat, for example. There's no merge, is one that's powerful, where you can merge two observables together and mix their events, sort of thing, which is fine, because like I said, we've got Lodash for events.

This now, literally, RxJS and Lodash are on the same path where Lodash existed before arrays had so many nice features. I think arrays used to just have filter and map and I think maybe reduce. Now, there's flat map and all these a variety of ways you can use an array now that didn't exist whenever Lodash first came out. Now, I think that RxJS is probably going to be in the same path, which is fine. It's great. I'm happy to relinquish control of that, too. There's no reason that Ben Lesh, of all people, should be the arbiter of everyone's favorite async push based type. It's probably not a good state for the world to be in if that's the single point of failure for that, because I'm not that great of an open-source maintainer.

[0:38:51] JG: I don't know, Ben. You've distributed, or demonstrated a lot of the really common positive attributes of an open-source maintainer, which is you wish people would use fewer of the features of your library. You've expressed excitement about pushing it to a better place, in this case, the web platform. To me, those are pretty good indicators that you're doing a good job.

[0:39:07] BL: Well, great. I'm glad. I'm glad to hear that.

[0:39:12] JG: Yeah. What does that mean for the next major version of RxJS? Are you just going to be a thin wrapper around observables?

[0:39:16] BL: I'm working on it now. I had to put it out. Originally, the next major version was going to be, I remove all the deprecated stuff, make the total size of RxJS another 20% smaller, because I cut it in half the previous version. I was going to make another 20% smaller in this version. Then, this proposal caught on and I was like, okay, but then it really caught on and I'm like, okay, this is actually going to happen, and it's going to be maybe a little different shape than our observables.

I stopped all new production on RxJS code, because I wanted to make sure. I thought it'd be silly to release RxJS 8, and then immediately afterwards, here's RxJS 9, the thing that is wildly different, because it's trying to make peace with the platform. Right now, and especially also, because it's just me working on this, right now, what's going to happen is RxJS 8 is going to end up being targeted at the web platform shape of observable and wrapping that and relying on a polyfill that we'll provide if you don't have it, because there's going to be people that don't have it. Then, RxJS 7 will exist for a very long time. I don't know how long I'll extend my support of that, but we're going to have to keep it going for quite some time, because there'll be a lot of people that are stuck on RxJS 7, or using RxJS 7, until we figure out, until I figure out how to wait to provide some backwards compatibility, or migration path for folks, if that's even necessary.

If you're using RxJS 7, hell, if you're using RxJS 6, it's fine. You probably want to move to 7, because it's faster and smaller. But if your app works, I would not spend tons of money and time updating something like that, unless you really, really were excited about it, or there was some great pressing reason to do it. Younger me would be like, "No, you update to the newest thing all the time. Don't be crazy. You're going to get so behind." But older and more experienced me has learned like, oh, it's okay if you're using this old version of whatever. There's features to ship and make sure everyone's getting paid and making money at your company and don't worry about what version of RxJS you're on.

I'll do my best to try to provide a path for people and also make sure this version of RxJS 8 is a lot more simple and hopefully, hopefully at the end of that, I can just watch it and make sure it stays on a good course. As I stated before, there's only so many times you can, so many ways you can write a window win, or whatever. Doesn't require a ton of maintenance, once it's up and running. It's not like a framework or something, where the platform is shifting underneath it. This is pretty close to the metal, JavaScript stuff.

[0:42:02] JG: You are working at primitives. We recently had recently interviewed Jessica Janiuk from Angular, for example, who went on in detail about all the interplays between streaming and suspense and server rendering and delays and deferrables. Yes, it's great to not have to deal with that ever-shifting target of what users need and what the browser does, but at the same time, you are dealing with complex data. I mean, at the end of the day, moving from RxJS, let's say, six to seven, or even six to eight is a very amorphous, hard to measure task, compared to, say, just upgrading your TypeScript version, right? There's a lot of stuff that's really hard to detect when it asynchronously breaks unexpectedly.

[0:42:40] BL: I think, the thing about it is that the contracts are like, when each thing should happen is very academically constrained. There's a set of guarantees. You can't next after you error. You can't error twice. There's all these things as like, if there's an error before, and this is actually fairly recent, because not every version does this, but if there is an error, you tear down everything. As soon as you know that something bad has happened, you tear down everything and then you push the error. There's all these rules that exist about how it's supposed to behave, such that the only real rule that's changed with the new observable in the platform is that it is ref-counted and multicast.

In some ways, may surprise some folks. In other ways, and most of the time, I think, is going to be helpful to people, because the reason that decision was made is because the very, very primitive version of observable, which is cold by default, and we'll start a new subscription for every time you subscribe all the way up to the chain, that behavior, I think, despite being the more correct behavior, the academically correct behavior and the more composable behavior, I think that behavior confused some folks. A lot of people were thinking, "Oh, well. If I start this stream over a web socket and I subscribe to it seven times, there should only be one web socket." What would happen if you wrapped it with an old observable with it's open and web sockets for every many subscriptions, unless you shared it or whatever.

If you go through and you look at people's code bases that use a lot of RxJS, everything's like share, share, share, share, share, to prevent that from happening. This is does that behavior about default. That's the only place that it will really get hairy when people go to convert things over. There's other things that would require some manual work. For example, RxJS 7 uses these pipeable operators. With pipeable operators, you're basically doing functional piping. The reason that exists is so we don't bloat bundle sizes by adding a bunch of methods. Well, the platform just has methods on the observable. We need to come up with a better way to do that. I think I've developed a pretty good way. We'll see how that goes through alpha.

Then, we need to make sure that we still support the old pipeable operators and all these. There's a variety of things that have to happen. It's definitely not going to be easy. I would never sit here and be like, "Oh, it'll be easy." Then someone else will listen to this at some point and be like, "God. That Ben Lash. That bastard. I can't believe you said it would be easy." No. But you'll get paid for every hour that you do it. I guarantee it. Well, I don't guarantee that. You could be open source, you pour bastard. But you're not working in open source. Then you're ideally collecting a paycheck while you're doing this and enjoy. Enjoy the money. You're welcome. Thank you.

[0:45:39] JG: Cool. Well, that's all the time we have for RxJS, as much as I would love to dive into so many of the cool things in it. I just have one last question for you, Ben. I'd like to end with something not technical. You dropped out of art school, but you're still an artist. Can you tell us, are there any particular artsy things you've done recently that you found?

[0:45:57] BL: Oh. Well, the most recent thing I did was, and it was the first oil portrait I have done in, God, 20 years, probably, is I painted a portrait of my parents. My mom, my poor mom, she's terminally ill. After art school, I'd never gotten them any paintings ever. I went and started working and I was busy and I had kids and blah, blah, blah. I never painted anything and gave it to my parents. This last, I think, maybe a couple months ago, I had finished a pretty good size painting. It was three feet by two feet, or maybe a little bit larger, portrait of both my parents side by side, like the classic portrait thing. I was able to present that to my mom. That was a big deal.  That was a big deal.

[0:46:38] JG: Do you still draw often? I think I remember you drawing at a conference.

[0:46:42] BL: Yeah. I think I drew a picture of you, actually. I drew a picture of you when you're on stage. Yeah, I do draw. I have a sketchbook that I bring around. Usually, I do it on trips. When I'm here at home with kids and work and housework and everything, I don't get the time I'd like to to do it. If I do it, it bothers me when I get distracted in the middle of it. If I go to a conference, sometimes I'll sit there and I'll sketch the speakers on stage, or if I'm traveling abroad, or I'm at an amusement park with my kids and they're off doing their thing, I'll sit somewhere and I'll just sketch people I see sitting around. I like that. That's the best way I do art these days is just quick pencil sketches of random people as I'm roaming about.

[0:47:24] JG: Well, I'm just curious now, to end the interview on the curiosity note, you get so much out of open source, clearly. You've had a wide impact. You've improved the platform. You've tackled very many interesting problems, design, code, etc., with RxJS. What are the parts of your brain that you find are being scratched by the drawings, the art side, the arts by RxJS in your day-to-day job?

[0:47:44] BL: I mean, they both do the same thing. You're building something from scratch, right? There's a process. You're building something from the ground up. You have to anticipate the next thing you're going to do while you're doing it. If it's a painting, you start with an underpainting and then you build layers up and you think about where's the dark and where's the light and what do I need to accentuate over what the actual photo shows and those sorts of things. You're problem solving effectively in order to produce something that other people can enjoy. It's the same thing for me with open-source work and stuff I do at work. I am generally problem solving to give something to other people that they'll enjoy, so. That sounds sappy, right? But it's true. It's true. That's what I do.

[0:48:34] JG: It's a lovely sentiment. It's a great way to end the interview. Ben, if there is anything people wanted to find out more about you, about RxJS, is there some place, or set of places on the Internet you would direct them?

[0:48:43] BL: Oh, let's see. I'm on my Twitter @BenLesh. I'm on Bluesky @benlesh.bsky.app. For now, I didn't put my custom domain in. I'm not that cool. Yeah, those would be the two places you could find me, other than going and trolling on issues on GitHub. Feel free to ask me questions. I try to be helpful with people if they message me. I do try to respond. Although, Twitter's DMs used to be my go-to spot and recently, they've gotten so gnarly with so much spam that I have a hard time even opening it and paying attention to it. I'm sorry if you message me in there and you fall in with all the other people trying to get me in some cryptocurrency scheme, so.

[0:49:23] JG: I do have this one blockchain. Just kidding. No, Ben, thank you so much for coming onto the show. This was fantastic. We talked about RxJS and observables and the platform and I'm really excited for where you're taking the project. This is good stuff.

[0:49:34] BL: Thanks Josh. I'm happy to see your face again.

[0:49:37] JG: Yeah, it's been a bit. Cheers. Thanks for listening y'all.

[END]